A claim file is an assembled thing. Photographs from a phone, a police report as a scan, invoices from three suppliers, a medical letter, an adjuster's notes, correspondence spanning months — arriving in every format, from every direction, over a period during which the claim may change shape entirely. The document handling is not incidental to claims work; a file that is disorganised is a file that is slow to settle and hard to defend. This covers the practical side, from both the claimant's and the handler's perspective.
The intake problem
Documents arrive as email attachments, portal uploads, photographs of paper, faxes in some markets, and post. The first decision is what "the file" actually is, and the answer should be: one canonical, ordered, searchable set, not an inbox.
Practical intake rules:
- Convert everything to PDF at the door. Photographs, Word files, spreadsheets, emails. One format makes the file navigable, printable and archivable. Images convert in bulk: how to batch convert images to PDF.
- OCR everything that arrives as an image, without exception. A claim file you cannot search is a claim file where somebody will miss the exclusion clause. How to make a PDF searchable with OCR.
- Name consistently at intake, with the date, claim reference, document type and source:
2026-08-05_CLM-4471_Invoice_ArdenRoofing.pdf. See naming and versioning shared files. - Record the source and date of receipt as metadata or in an index, because "when did we receive this" is a question that comes up in every disputed claim.
- Never edit the received document. Annotate a copy; keep the original as received. This is the single most important rule in the whole workflow.
Photographs, which are most of the volume
Damage photographs are the bulk of a modern claim file by file size and often by count, and they are handled badly more often than anything else.
- Keep the originals. The EXIF metadata in a phone photograph — timestamp, GPS coordinates, device — is potentially evidential. Converting to PDF or resizing frequently destroys it. Store the original images alongside the PDF rendition, not instead of it.
- Compress the renditions, not the originals. A claim file with 200 uncompressed phone photographs is several gigabytes and unusable. How to compress a PDF without losing quality and why is my PDF so large.
- Caption them. A photograph without a caption saying what it shows and when is of limited use six months later. A contact sheet page with captions at the front of the photographic section costs ten minutes and saves an hour per subsequent reader.
- Be aware of what the metadata discloses. GPS coordinates in a photograph sent to a third party disclose a claimant's home address. See hidden data in PDFs explained.
Assembling the claim bundle
At various points — internal review, referral to an expert, litigation, complaint to an ombudsman — the file has to be assembled into a bundle somebody else will read.
- Merge in a logical order with a contents page: policy documents, claim notification, correspondence chronologically, invoices, expert reports, photographs. How to combine PDF files.
- Bookmark every section, so a reader can navigate a 400-page bundle: how to add bookmarks to a PDF.
- Number the pages continuously across the bundle. Once a bundle is discussed by more than two people, unique page references stop being a nicety. The technique and its rules are in Bates numbering explained.
- Include an index mapping documents to page ranges.
- Keep the bundle reproducible. Record which documents went into it and in what order, so a later version can be produced consistently.
Redaction, which comes up constantly
Claims files contain other people's personal data, medical information, and material that must be removed before parts of the file are shared.
Recurring cases:
- Third parties in a photograph or a police report — witnesses, other drivers, bystanders.
- Medical information shared beyond those who need it.
- Bank details on invoices and settlement instructions.
- Other claimants' data where a document covers several matters.
- Reserve figures and internal assessments in a file being disclosed to the claimant.
Redaction must remove, not cover. A black rectangle over a bank account number leaves the number in the file, retrievable by anyone who selects the text. This is a well-documented and repeatedly embarrassing failure — see PDF redaction failures and how to avoid them and how to redact text in a PDF. Strip metadata from redacted documents as well: how to strip metadata from a PDF.
Where a redacted version is produced, keep both the unredacted original and the redacted rendition, clearly labelled, with a record of what was removed and why.
Data extraction from invoices and estimates
A high proportion of adjusting time goes on reading invoices and repair estimates and transcribing figures. This is exactly the shape of problem that structured extraction handles well: AI data extraction from PDFs and extracting tables from PDFs with AI.
Two constraints that should shape any such system:
Numbers need validation, not trust. OCR and models both make errors that read fluently. Totals should be checked against line items, dates against plausibility, VAT against the arithmetic. The failure mode described in OCR language support and accuracy — that language models fix prose errors and have nothing to say about digits — is precisely the risk here.
Claims data is personal and often special-category. Health data in particular attracts additional protection under GDPR. Routing it through a third-party AI service is a processing decision requiring a lawful basis, a processor agreement, and usually a DPIA. See risks of using AI on confidential PDFs, GDPR and PDF documents, and for medical material HIPAA-compliant PDF handling.
Fraud and document integrity
Claims is one of the few document domains with an active adversary. Altered invoices, edited receipts, backdated documents and duplicated photographs are all part of the landscape.
What is actually checkable:
- Metadata inconsistencies — a "2024 invoice" whose creation date is last week, or whose Producer string is an image editor rather than an accounting package.
exiftoolshows this in seconds. - Font and layout anomalies — a figure in a different font or slightly misaligned, indicating an edit. Real invoices are generated consistently.
- Incremental update history — a PDF's structure can retain earlier revisions of the document, which sometimes preserves the pre-edit values. See PDF incremental updates explained and how to detect tampered PDFs.
- Photograph metadata — timestamps and coordinates that do not match the claimed incident, or images whose EXIF shows editing software.
- Duplicate detection across claims — the same photograph submitted for two incidents.
None of these are proof on their own, and all of them have innocent explanations. They are indicators that direct further enquiry, not conclusions.
Retention and closure
When a claim closes, the file does not disappear:
- Retention periods are set by regulation, limitation periods, and reinsurance requirements, and are typically long — often six years from settlement, considerably longer for liability and injury claims where limitation runs from knowledge. See document retention policies.
- Archive in a durable format. PDF/A for the bundle, originals retained where evidential value matters. PDF/A archival format explained and how to archive PDFs long term.
- Delete on schedule. Holding claims files indefinitely is both a data protection problem and a disclosure liability.
- Preserve the search layer. An archived file with no OCR text is an archived file nobody can use.
For claimants
From the other side of the process, a few things measurably speed a claim:
- Send one clearly named PDF per document, not twelve photographs of pages of one letter.
- Photograph documents flat and in good light, or use your phone's document scanner rather than the camera — scanning documents with your phone.
- Keep your own copy of everything sent, with dates. Insurers lose documents, and a claimant who can produce a chronology is in a much stronger position.
- Do not annotate the only copy of an original.
- Check what your photographs disclose before sending them to anyone other than the insurer.
Summary
Convert and OCR everything at intake, never edit the received original, and name consistently from the start. Keep photographs' originals for their metadata while distributing compressed renditions. Bundle with a contents page, bookmarks and continuous page numbers, and redact by removal rather than by covering. Validate every extracted figure — the error you will not notice is a digit, not a word — and archive to PDF/A on a retention clock you actually enforce.