Merge, Flatten, Watermark, Organize, Upload-ready’s fix and Leak Check’s Sanitize give the same warning; when merging, only the first document’s XML can be kept, and the warning says so. After Leak Check’s Sanitize, a kept XML and its metadata are listed again by the re-check — that is expected. Other tools that write a new PDF — Split, Extract pages, Delete pages, Mix, Unstack, Remove metadata and PDF to PDF/A among them — do not check for an e-invoice and can drop the XML, so keep the original. The compression itself is the same as for any PDF: three levels whose real sizes are measured on your device, or an exact size limit, with text never rasterised. Bindery reads and preserves the e-invoice; it does not validate the invoice against the full EN 16931 schematron. The file never leaves your browser.
How it works
- Drop the invoice PDF — Bindery finds the attached XML and warns before compressing
- Choose to continue and keep the XML, then pick a level or type an exact size
- Download the smaller PDF, and drop it into Upload-ready to read the invoice back from the kept XML
Questions people ask
What exactly does “keep the XML” restore?
Three things from your original file. First, the /AF entry on the document catalog, which names the embedded invoice as an associated file. Second, the embedded XML itself — factur-x.xml, zugferd-invoice.xml or xrechnung.xml — in the document’s embedded files, with the /AFRelationship (Data, Alternative or Source) on its file specification. Third, the original XMP packet: its PDF/A-3 identification, the fx: description (DocumentType, DocumentFileName, Version, ConformanceLevel) and the PDF/A extension-schema declaration that describes it. The colour profile the file declares, its output intent, is copied too.
Will the compressed file still be a valid PDF/A-3 e-invoice?
Keeping the XML also restores the original XMP packet, with its PDF/A-3 identification and Factur-X schema declaration, and the colour profile; Bindery does not re-check PDF/A-3 conformance on the output, so if your recipient checks PDF/A, run the result through their validator or veraPDF. Nor does Bindery check the invoice against the full EN 16931 schematron: it carries over the XML you already have, unchanged, and does not rewrite or correct it.
Can Upload-ready keep the XML too?
Its fix gives the same warning and the same choice. Upload-ready destinations that forbid attachments (Government or visa portal, Court e-filing, Long-term archive (PDF/A)) cannot keep the XML and still pass that rule. The same holds for the No author or software metadata rule and the PDF/A-2b rule, which does not allow an XML attachment: with the XML kept, those rules are reported as not met. For an e-invoice, the Email attachment destination, or Compress on its own, is the better fit.
Is it free, and is the invoice uploaded?
On the free plan compressing counts as one of three completed jobs per UTC day, files go up to 25 MB, and free exports carry a small “Made with Bindery” watermark, which changes the visible page but not the XML. The invoice is compressed in your browser tab and never uploaded; there is no server copy to delete.