The invoice and its XML: paperwork that has to travel together

Some documents are useless on their own. The invoice PDF is the readable part; the XML behind it is what the client’s accounting software actually reads. The report is the readable part; the spreadsheet with the numbers is what anyone will ask for the moment they disagree with a total. Send only the PDF and half the job is missing. Send two files by email and they’re separated within a week, because someone forwards one and forgets the other, or the attachment gets stripped, or the folder gets tidied.

PDF has had an answer to this for years, and it’s not a workaround: you can put the other files inside the PDF. reader.me now does it in the browser with attach files to a PDF. Pick the document, pick what goes inside it, save. One file leaves your hands.

What “inside” actually means here

It’s not a link, and it’s not a zip with a PDF in it. The files get written into the PDF’s own structure, as embedded files. Open the result in any decent reader and there’s a paperclip icon or an attachments panel listing what’s in there, with a button to save each one back out. The pages look exactly the same as before; nothing is stamped on them, nothing is moved.

The important consequence is that the attachment survives the things that normally break a pair of files. Forwarding the email. Uploading it to a client portal. Saving it to a shared drive six months later. If the PDF made it, the spreadsheet made it.

Any file type works, by the way. It doesn’t have to be another PDF. Spreadsheets, XML, CSV, images, a .zip of raw data, an .eml of the email thread that started it all.

Where this earns its keep

The good cases are boringly specific:

• An invoice and its structured version. This is exactly how the hybrid e-invoicing formats work: a PDF a human can read, carrying inside it the XML a machine can process. One file, two audiences, no chance of the two versions drifting apart.
• A report and the spreadsheet the numbers came from. The person reviewing your work will want to check a figure. Attach the workbook and you’ve answered the email before it’s sent.
• A signed contract and the original quote. The PDF everyone signed, carrying the version the client actually sent you, in the format they sent it in. Handy the day someone remembers the price differently.
• A paper and its raw data. Researchers have been doing this for a long time, and it’s one of the few ways a dataset stays attached to the conclusions drawn from it.

If you already work this way with quotes and invoices, the workflow in invoices and contracts without uploading anything fits alongside it neatly: sign, attach, send, all on your own machine.

Say it plainly: attachments are not encrypted

This is the part that gets buried in most explanations, so here it is in the middle of the article instead. An attached file is not encrypted. It’s stored compressed, which is a completely different thing. Anyone who has the PDF has the attachment, and getting it out is a two-click operation in any reader.

The rule is simple: if you wouldn’t send it as an email attachment, don’t attach it here either. Client bank details, an internal cost breakdown, personal data of people who aren’t part of the conversation. Those don’t go in, however convenient it would be.

And a related habit worth having: know what’s already inside a document before you pass it on. Attachments are one of several things a PDF can carry without showing you on the page, which is the whole point of checking a PDF’s hidden metadata before it leaves. If you want the full picture of a file you’ve been sent, pdf metadata shows you what’s declared inside it.

It shows you what’s in there first

Before touching anything, the tool lists the attachments the document already carries. That matters more than it sounds. Plenty of PDFs arrive with things already inside them and no visible sign on the page. You get to see that list, and you get to save those files out, before you add anything of your own.

Adding never replaces. Whatever was in there stays in there, keeps its name, and comes out the other side. If a file you’re adding happens to have the same name as one already inside, the new one gets numbered (report (2).csv) so the reader doesn’t show you two identical rows.

You’ll also see how much the attachments are about to add to the document. Text-heavy files like CSV or XML compress well and cost almost nothing. Anything already compressed — a JPEG, a zip, another PDF — goes in at roughly its full size, because there’s nothing left to squeeze.

The limits, and one thing it won’t do

Twenty files, 50 MB total in one go. On an iPhone the browser gives a page far less memory to work with, so the tool lowers its own ceiling to match instead of letting the tab die halfway through.

The one refusal: it won’t attach to a password-protected PDF. Adding files means rewriting the document’s structure, and doing that to an encrypted file half-blind is how documents get corrupted. Remove the password first, attach, then protect the result if you need to.

Everything happens in your browser. The PDF, the spreadsheet, the invoice XML — none of it is uploaded anywhere, because there’s no server involved in the operation at all. Which, for a document that carries your client’s numbers inside it, is rather the point.