The forms are done and the evidence is scanned. What you actually have is one 84-page PDF holding three clients' paperwork, forty-two blanks the duplex feeder inserted and an exhibit that came out sideways — plus a checklist saying it must arrive as one ordered, paginated submission.
Each of these tools is simple on its own. The mistakes are not in any one of them — they are in the order they get used. Merge before you flatten and the filled values are at risk; number before you trim and the sequence is wrong.
Flatten every filled form before it goes near a merge. Split only if the batch is one document per page; if it holds multi-page documents, keep ranges instead. Drop blanks and fix rotation before merging. Number last, once, across the finished packet — and if the exhibits already carry numbers, decide which sequence wins before you file. If the packet runs to hundreds of pages, or the rules specify bookmarks or Bates numbering with a case prefix, this is the wrong toolset.
The pipeline
| Step | If you skip it | If you do it out of order | Tool |
|---|---|---|---|
| 1. Flatten filled forms | Two copies carry identical field names | Too late — the collision has happened | Your filler's export |
| 2. Separate the batch | Three clients stay in one file | Splitting after a trim repeats the trim | Split |
| 3. Drop blanks | Blanks read as missing exhibits | Trimming after numbering leaves gaps | Keep or remove pages |
| 4. Fix rotation | Sideways pages; illegible copies can be rejected | Rotating later turns the stamp too | Rotate |
| 5. Merge in order | Several files arrive, not one | Merging first carries the blanks in | Merge |
| 6. Paginate | No page is citable later | Numbered parts give competing sequences | Page numbers |
Step 0: flatten, before anything else touches the file
A PDF form field is addressed by name, and its fully qualified name is built from its own partial name plus those of all its ancestors (ISO 32000-1, 12.7.3.2). Two copies of one blank form therefore carry fields with identical fully qualified names, so merging them is a name collision by construction. Acrobat warns about it directly: combine documents whose field names match and it tells you those fields are now one field, and that keeping the values separate means a portfolio instead.
What happens next depends on the tool, so I tested it: one copy of a two-field form filled with ALICE ABLE / AAA-1111, a second with BOB BROWN / BBB-2222, neither flattened, merged two ways. Filly's merge — pdf-lib's copyPages underneath — produced a file that looks entirely correct: both values render and both extract cleanly as text. But the output carries no AcroForm at all. The two field dictionaries survive orphaned, both still named FullName, one holding ALICE ABLE and the other BOB BROWN; asked to list the fields of its own output, pdf-lib returns zero. qpdf 12.3.2 did the opposite: it rebuilt the form and renamed the collision into four live fields — FullName, CaseNumber, FullName+1, CaseNumber+1 — so the second copy no longer carries the names the form was built with.
Neither gives two copies each with its own live, correctly named fields — which is why you strip the fields before the merge. An open pdf-lib issue reports this exact workflow producing a file where Adobe Reader shows blank fields on the pages after the first while Chrome and Foxit render them fine. Your reviewer opens it in Acrobat.
A form Filly filled is flattened on export, so nothing is left to collide; a form you filled in Acrobat or Preview and saved is not. The check takes two seconds — open the merged file and click where a value should be. If a caret appears, it is still a live field and still at risk.
Splitting a batch that is not one document per page
Split explodes a PDF into one file per page and returns a zip. It cannot tell where one document ends and the next begins — nothing in the file says — so a three-page exhibit comes back as three loose files. Split is right when the feeder ate a stack of unrelated single sheets, wrong when the batch holds multi-page documents; for those use page selection and keep ranges, 1-3, 4, 5-9, so each document survives intact.
It also clears the feeder's other artefact. Run a single-sided stack through a duplex scanner and every blank back becomes a page: twice the length, a blank behind each sheet. Immigration court filings are meant to be single-sided to begin with, which is why the pattern turns up so often. Removing the even pages usually clears it in one pass. Do it before the merge — a blank in a filed packet reads, to somebody checking against a table of contents, as a missing exhibit.
When describing it is faster than counting it
Finding which of sixty scanned pages are the signed ones means opening sixty pages. AI organise takes the sentence instead: you describe the change, the model reads the page text and works out which pages that means, and a deterministic function copies those pages into a new file. The model chooses the pages; it never touches the bytes.
Be exact about what it does not give you. It runs in one pass: you get the finished PDF back with a short note saying what it kept, not a plan to sign off first, so the reviewing happens on the output. Check it against the page count you expected, because an ambiguous instruction can be read the wrong way. And, decisively for a scanner batch, it reads the text layer, not the image — pages with no extractable text reach the model labelled as such, so a scan that never went through OCR gives it nothing to work with. On a free account it costs 2 credits where the rest cost 1.
Merging in the order the checklist specifies
Pick order is page order, so the pick order is the checklist — and for an immigration court filing that order is set out for you: cover page, application or motion, proposed exhibits with their table of contents, proof of service. Merge carries each page across exactly as it is: it does not re-flow text, re-number footers a source document already carries, or reconcile a table of contents — if your index says an exhibit starts on page 12, merge will not notice when it does not. Two files minimum, 25 MB per upload.
Why numbering comes last
The page-number stamp is drawn bottom-centre, at a fixed height, on every page, reading "1 / N". It cannot find, replace or renumber pagination a source document already carries — it only adds. A packet built from pre-numbered exhibits therefore shows two competing sequences, and the stamp can land on an existing footer.
Continuity is the requirement, and the argument for numbering the assembled, trimmed file rather than the parts. The EOIR Immigration Court Practice Manual asks that all documents — briefs, motions and exhibits alike — carry consecutive numbers at the bottom centre or bottom right of each page, with a table of contents identifying page numbers for exhibits. Consecutive is the operative word: a number stamped on a component is wrong the instant it is merged behind something else. And "page 34 of 51" is answerable where "the third page of the second exhibit" is not.
The five-minute check before you file
Page count against the checklist. No blanks. Nothing sideways — and note that rotating a page in a viewer is not always rotating the file: Acrobat separates View > Rotate view, which is temporary and gone the next time the PDF is opened, from Organize Pages, which saves it. Then one numbering sequence. Then — the step people skip — open the finished file in a plain viewer rather than the tool that made it, because producing tools are forgiving of their own output.
Where this toolset is the wrong answer
It builds no table of contents, no bookmarks and no exhibit index — and the practice manual asks for a table of contents with page numbers, so that is yours to write. There is no Bates numbering, the AI tool cannot read a scan that never went through OCR, and every operation is capped at 25 MB per upload. Nor is there a public API: a person runs this sequence, one packet at a time.
On cost: split, page selection, merge, page numbers and rotate each spend one credit on a free account, AI organise spends two, and a paid plan spends none. Signing up grants 10 credits; the free plan covers 10 fills a month. The guide to filling the forms themselves covers the step before this one.
Frequently asked questions
Why did my merged packet lose its filled-in values?
Because they were still live form fields. Two copies of one template carry fields with the same fully qualified name, and merging forces a resolution — dropping the form structure, renaming the duplicates, or collapsing both into one field with one value. Flatten before merging and nothing is left to collide.
How do I get rid of the blank pages a duplex scan added?
Duplex scanning a single-sided stack puts a blank behind every sheet, so they land on the even pages and removing those usually clears them in one pass. Check the pattern before merging — one misfeed shifts it.
Can I split a PDF into documents rather than pages?
No. Split produces one file per page and cannot detect document boundaries. Keep the ranges you want with the page-selection tool instead, one document at a time. The AI tool has the same shape — it returns one trimmed PDF, not a set of separate documents.
My exhibits already have page numbers — should I add more?
Usually yes: the practice manual asks for consecutive numbering across the filing, and a component's own numbering restarts wherever that component starts. The stamp cannot replace existing numbering, so both stay visible — cite the packet-level sequence in your index, and expect a reviewer to see two.
Does Filly do Bates numbering?
No. It stamps a fixed "N / total" at the bottom centre — no prefix, no case number, no starting offset, no choice of position. For Bates numbering, use a litigation-support product.
Will merging reduce the quality of a scan?
No. Each page is copied across as it is, not re-rendered or re-compressed. What merging cannot do is rescue a page that scanned badly, and illegible copies can be rejected or excluded from evidence — re-scan rather than hope.