A document manifest is a short inventory of the files that belong in a packet and the order in which they should appear. It helps you notice missing, duplicate, outdated, or mislabeled sources before you merge. The manifest does not prove that a document is accurate or authorized for sharing; it records what you selected and what you checked. For a small two-file task, a simple list may be enough. For a larger packet, a table provides a clearer review trail.
Decide what the manifest needs to answer
Start with the questions a reviewer may ask: Which source version was used? Where does each section begin? Are all expected documents included? Does the final page count match the source set? Select only the columns that help answer those questions. A typical table includes sequence number, filename, document type, date on the document, source page count, intended recipient, and verification note.
Do not add personal data that does not help identify the file. A manifest can itself contain sensitive details, especially when filenames include account numbers, medical identifiers, or addresses. Store it with the same care as the packet and share it only if the recipient needs it. A neutral internal ID may be safer than copying confidential information into a second file.
Record source versions consistently
Use a stable naming convention for working copies. A sequence prefix such as `01`, `02`, and `03` can make whole-file ordering easier to review. Include a revision date when files change. Avoid names such as `final-v2-revised-final.pdf`, which make it hard to determine which version is authoritative. Keep an unchanged source copy and make working copies for page rotation, correction, or export.
Record dates that appear on the document separately from the filesystem’s modified timestamp. A scan created today may show a form dated several months earlier. These dates answer different questions. When the content does not show a date, mark it “not shown” instead of guessing. If a source file was replaced, note the new filename and review the entire affected section again.
Check inclusion, order, and duplicates
Before merging, compare the source folder with the list. Confirm each intended document appears once, that no unrelated item is selected, and that any multi-page source includes its full page range. If a source has pages that should not be included, use a tool with page-level extraction or removal and save a separate copy; Folio Bench’s merge control reorders whole files only.
Decide how related documents should be grouped. The recipient’s instructions take priority. If no order is given, choose an order that supports the review task, such as an index, primary document, and supporting records. If there are several date-based records, choose ascending or descending order deliberately and state it in your manifest. Do not mix sorting methods without a clear reason.
Verify the output against the manifest
After merging, open the output and compare its section order with the list. Add the expected page counts for each source and compare the sum with the output’s page count. A mismatch may indicate a missing document, an unsupported source, or an accidental extra page. Check the first and last page of each segment and any page with a changed orientation.
If the packet changes, create a revised manifest rather than silently replacing the old one. Record which source changed, why it changed, and which output was inspected. Keep the previous output if the process requires a history. This is a practical tracking record, not a digital audit trail: it does not prove who created or reviewed the files, and it can be edited like any ordinary note.
Example manifest fields
| Order | Source name | Document type | Date shown | Pages | Check before merge |
|---|---|---|---|---|---|
| --- | --- | --- | --- | ---: | --- |
| 01 | cover-copy.pdf | Cover | 2026-11-01 | 1 | Recipient name and date |
| 02 | request-form.pdf | Main form | 2026-10-28 | 4 | Fields and signatures |
| 03 | receipt-scan.jpg | Supporting image | Not shown | 1 | Crop and legibility |
The entries are illustrative. Replace them with your actual documents and verify the page counts. Do not infer that a sample file type, date, or sequence applies to a particular recipient.
Protect authoritative originals
Some documents should remain in their original form, especially signed PDFs, fillable forms, or records whose metadata or attachments matter. A manifest can identify those originals as separate sources without requiring them to be merged. If the recipient wants one combined visual packet as well, ask whether the original files must also be submitted.
The merge utility copies page content into a new document and may not preserve signatures, forms, bookmarks, attachments, metadata, or accessibility features. Keep the original file and note any limitation in the manifest. Do not label a merged convenience copy as an unchanged signed source.
Frequently asked questions
Is a spreadsheet required for a manifest?
No. A numbered list is adequate for a small packet. Use a spreadsheet only when its columns help you compare versions, page counts, or review status.
Should I include hashes or checksums?
Only if your process requires them and you can generate and verify them correctly. This site does not calculate cryptographic file hashes or maintain an audit log.
What if the manifest and final page count differ?
Stop and compare the source list with the output before sending. Check for skipped files, duplicate pages, or an incorrect page count in your notes.
Can I send the manifest with the packet?
Only if the recipient wants it and it contains no unnecessary sensitive information. The manifest may be useful internally without being part of the final submission.
Related guides
See how to sequence a PDF packet, the PDF handoff checklist, and the local merge guide.
Sources
- Adobe: Combine files into one PDF — describes arranging and reviewing files and pages before combining them.
- PDF-LIB PDFDocument API — documents copying pages from source PDFs into a new document.
- Folio Bench merge tool — states the whole-file reorder behavior and output limitations.