A batch needs more than a document count
A batch may contain different years, document types, page counts and output requirements. Listing those differences helps identify standard-plan work and items needing a separate quote.
A company list requires retrieval first. Existing PDFs start with extraction assessment. Avoid arranging retrieval again for the same version you already hold.
A document list everyone can follow
Scroll sideways to see all columns; focus the table and use arrow keys on a keyboard.
| Item | What to provide | Why it matters |
|---|---|---|
| Your reference | One distinct reference for each request | Match results back to the request |
| Company and document | Full name, known identifier, document type and date | Reduce name and year ambiguity |
| Available input | PDF filename and page count, or retrieval needed | Separate retrieval from extraction |
| Output requirements | Standard JSON / XML, review or target format | Establish standard versus custom scope |
Start with representative files
Choose a few files representing the differences in the batch: a short filing, a longer document and different years. Agreeing a format against only the easiest file can miss the variation in later work.
Agree the requested fields, how to locate the source and how unreadable or incomplete items will be reported. This establishes delivery scope; it is not a manual review of the whole batch.
Example: split 20 requests by input
For example, 12 of 20 requests already have PDFs and 8 need retrieval. Separate those groups, then check types, dates and pages to estimate extraction-only work and retrieval plus extraction. Batch pricing depends on the agreed scope.
A handover example: a next step for every request
These three fictional rows illustrate a handover. Use the same internal reference to track what has arrived, what is missing and who needs to act.
Scroll sideways to see all columns; focus the table and use arrow keys on a keyboard.
| Reference | Received | Outstanding item / next step |
|---|---|---|
| Example A01 | Original NAR1 PDF, 8 pages | Recipient checks the company and date, then arranges standard extraction |
| Example A02 | Company name only | Requester supplies the document type and date before retrieval |
| Example A03 | NAR1 excerpt, 2 pages | Member details requested; obtain the relevant pages first |
Four points to agree before delivery
- Every requested item has a corresponding result or a status requiring clarification.
- Filenames, companies and dates match the request list.
- Standard extraction, manual review and custom work are identified separately.
- How missing, unreadable or unprocessed items are handed over, and how corrections and timing are agreed.
Ready to ask for a quote? Start with your list
You can enquire with document counts, representative files and output requirements. Mention any fixed format or integration needs so the documents, samples and delivery method can be agreed first.
The downloadable checklist contains fictional examples, not real company or personal data. Begin with counts and requirements; the file-transfer method is arranged after confirmation.
Count companies, documents and pages separately
“We have 50 companies” does not describe a document batch. A company may need several years, and a PDF may contain several filings. Record company count, expected document count and received PDF count separately. Keep unknown counts unresolved so that missing retrieval and unclear file boundaries are not confused.
In a fictional batch, ten companies each need two years, giving twenty document requests, but the folder contains sixteen PDFs. That does not establish that four documents are missing: some files may be combined or duplicated. Map each requested filing to its source file before identifying unresolved items.
Page count describes size and helps assess plan eligibility; it does not establish completeness. “Twelve pages received” and “complete filing confirmed” are different observations. Record only what was inspected or confirmed, rather than marking every item complete to make the inventory look tidy.
Try a few files before processing the full batch
Representative files reveal variation early. Choose examples from the actual batch that cover a common layout, longer material, readability issues and special output requirements. These are practical categories, not a prescribed sampling rate. Do not introduce irrelevant material merely to fill each category.
For example, you may want to add company names to an existing register. Ask the colleague who maintains it to try the sample: find the name, check it against the PDF and add it to the register. This reveals whether the format is useful in practice and whether any fields are missing.
Record which files were used, which outputs were agreed and which issues remain. “Sample OK” is too vague. A later variation can then be compared with the agreed examples instead of treating every disagreement as an extraction error. Approval of a sample does not establish accuracy across the entire batch.
Handle added files and changed requirements explicitly
Files often arrive after a batch has started. Identify each as a replacement, a supplement or a new request. A replacement names the item it replaces; a supplement identifies the missing part; a new request gets its own reference. Do not make the processor infer the effective version from email timestamps.
Use a change note: “Reference [ID]; action [replace/supplement/add]; new file [name]; previous file [name]; reason [details]; reprocessing of delivered output [to confirm].” Agree the affected work and any fee before reprocessing, so the owner understands whether other items are affected.
Even a field rename from A to B raises a practical question: should it apply only to future files, or should earlier results be updated too? Agreeing this helps everyone work with consistent tables instead of a mixture of old and new names.
Leave a clear note when something needs attention
“Failed” or “needs manual work” is not an actionable handover. Describe the request, observed issue, affected scope and what is needed from whom. Describing a problem does not establish its cause: for unreadable text, record its location and appearance without guessing whether scanning, printing or completion caused it.
A fictional note might read: “B-014: requested a specified-year NAR1; received date differs from the list; this file has not been processed; request owner to approve the available date or provide the requested filing.” It separates observation, work status and decision ownership instead of silently changing the year.
Keep the original observation when recording its resolution, decision and owner. If partial delivery is accepted, identify the accepted portion and treatment of the remainder. Do not erase the explanation by marking everything complete. These are team handover suggestions; agree actual exception categories and communication for the batch.
How to check a batch without missing anything
Check the batch in three passes. First, match each request to a result or an explanation of what remains outstanding. Next, open the files and make sure the fields, companies and dates are easy to find. Finally, compare the agreed fields with the source. Separate passes are easier to follow than trying to count files and check contents at the same time.
If the team samples results, agree who selects the sample, what is checked and what happens when an issue is found. No accuracy-guaranteeing sampling rate is proposed here. Inspecting a few successful examples demonstrates the delivery format; it does not establish that every document is error-free.
Close with: “Requested [count]; accepted [count]; partially accepted [count]; outstanding [count]; reasons in [list]; follow-up owner [role].” This defines the state of completion and creates a reusable record for the next batch.