One of the most persistent problems in contents claims is document importing.

On paper, importing a document sounds straightforward: upload a loss sheet or receipt, extract the items, and add them to the claim.

In practice, the files we receive are rarely straightforward.

Loss sheets and receipts come in as CSVs, Excel files, PDFs, scanned documents, handwritten lists, screenshots, emails, photos of creased paper, and pictures taken in poor lighting. Even when two files contain the same basic information, they often use completely different layouts, column names, and formats

A clean spreadsheet might include item descriptions, quantities, prices, rooms, and ages in predictable columns. A handwritten loss sheet might have missing headers, crossed-out notes, room names written in the margins, and totals mixed in with line items. A receipt might include claimable contents items alongside tax, shipping, discounts, loyalty numbers, payment metadata, and grand totals.

The challenge is not just reading the file. It is understanding what matters, what does not, and how to turn messy source material into structured claim data.

The old old approach

We first asked people to reformat their data and adhere to our formats. We told them in training, we put up warning indicators, and we added in robust error messaging.

That didn’t work.

It’s not that people are stupid or lazy. They’re busy. They don’t want to have to reformat a file or make sure they’ve used the right template.

They’ve got better things to do, and we don’t want to hinder them.

The old approach

Our next approach was a rudimentary but capable workflow.

The system looked at the file type and metadata, then routed the file to a specific processor. A spreadsheet went down one path. A table-like image went down another. A contents photograph went somewhere else.

That worked, but it created a growing maintenance problem.

Every new file type or edge case added more complexity. Each processor had to be maintained independently. Improvements to one path did not necessarily improve another. And the more real-world files we saw, the more obvious it became that claim documents do not fit neatly into fixed lanes.

The hardest cases were mixed or ambiguous files: a PDF with typed tables, handwritten notes, embedded photos, and extra pages; a loss sheet where the OCR table looked complete, but handwritten items appeared below it.

A rigid pipeline can miss those cases because it is optimized for the format it expects, not the document that is actually in front of it.

Why a fixed workflow was not enough

Our first attempt at solving this was a bounded, workflow-style parser.

It stayed mostly on rails, trying a series of extraction strategies and then checking whether the output appeared complete. We also added an adversarial review step to challenge the extraction before accepting it.

That helped, but it exposed the deeper problem.

Document importing is not always something you can verify with simple heuristics. A parser might successfully convert every OCR table row into an item row and appear to have captured 100% of the data. But the OCR strategy itself might have missed the handwritten bullet list underneath the table. On paper, the workflow succeeded. In reality, it missed claimable items.

The reviewer helped catch some of those failures, but the parser was still too rigid. It could only recover from problems that fit within the paths we had already designed.

And the files we receive can be strange. A single PDF might contain photos, handwritten notes, receipts, and a structured loss sheet. A fixed workflow can struggle because it has to decide too early what kind of file it is dealing with and how it should process it.

So we moved to a different architecture.

What we built instead

We built an agentic import flow.

The system starts by routing the uploaded file based on its actual content, not just its extension or metadata. Instead of only asking “what file type is this?”, it asks what kind of claim artifact the file appears to be.

For document-like files, the agentic parser takes over.

The agent has autonomy to choose the right extraction approach for the file in front of it. It can inspect layout text, table output, raw OCR, specific PDF pages, and previously loaded source context. It can decide when a table extraction is enough, when it needs a second OCR pass, and when it needs to inspect more of the document.

Once it has candidate item rows, it can use bounded tools to clean and normalize the data programmatically.

That means it can:

• add item rows from source text

• delete subtotal, tax, shipping, header, footer, and noise rows

• update individual fields

• apply bulk edits across many rows

• replace systematic OCR artifacts

• normalize casing

• assign room, store, quantity, price, age, and condition when supported by the source

That combination is the important part.

The agent is flexible enough to adapt to messy, unfamiliar documents, but constrained enough that it is not just free-writing claim data. It has to operate through tools, ground rows in the source document, and produce output that fits our claim item structure.

Why bounded tools matter

A fully free-form extraction agent would be risky.

Claims data needs to be defensible. We do not want a model guessing items, inventing prices, or smoothing over ambiguity just because the final output looks clean.

So the parser is given autonomy over the extraction strategy, but not unlimited freedom over the result.

Every row should be supported by source text or clear source context. If the file does not provide a quantity, price, room, store, age, or condition, the parser should leave that field blank rather than guess. Summary rows like tax, shipping, discounts, and grand totals should be excluded. Repeated items should stay repeated when they appear separately in the source.

The parser also uses tools for normalization rather than relying only on generated text. That matters for both accuracy and efficiency. If OCR consistently mis-cases item descriptions or adds the same artifact to every row, the agent can use a targeted normalization or replacement command instead of rewriting every item manually.

This reduces token usage, avoids unnecessary regeneration, and makes the cleanup process more controlled.

The review loop

One of the more important parts of the new system is that extraction is not treated as complete just because the parser produced rows.

The parser has to submit its working extraction for review.

A separate review agent checks whether the extracted rows are supported by the source context. It looks for missing items, unsupported inventions, incorrect granularity, weak provenance, and noise that should have been excluded.

If the review finds a problem, it returns structured feedback. The parser can then make targeted corrections and resubmit. The system allows multiple remediation rounds before failing the import.

This matters because document extraction is not always a simple “did OCR return text?” problem.

A file can produce clean-looking rows and still be wrong. The table might have been extracted correctly, but a handwritten list of additional items might have been missed. A receipt might include a total that looks like a price but is not a claimable item. A PDF might contain relevant pages mixed with unrelated content.

The review loop gives the system a way to challenge its own output before committing data to the claim.

Why this matters

The biggest benefit is that we no longer need a bespoke processor for every document shape we encounter.

Instead of expanding a brittle maze of file-specific logic, we can route messy files into a single extraction system that adapts to the document in front of it.

That gives us a few important advantages.

First, we can support a wider variety of real-world files. Adjusters and policyholders do not always send clean spreadsheets. They send the documents they have. The import system needs to meet them there.

Second, we can reduce hallucination risk by requiring source-grounded rows, bounded tools, and validation against our claim item structure.

Third, we can improve normalization without pushing everything into the model’s context window. Programmatic tools are a better fit for repeated cleanup operations like casing fixes, text replacement, and field updates.

Finally, we can make the system easier to extend. As we encounter new file shapes, we can improve the router, extraction tools, review criteria, and evaluation framework instead of building another one-off processor.

What this unlocks

This gives Adjusto a much stronger foundation for document importing.

Receipts, handwritten lists, mixed PDFs, screenshots, and loss sheets can now be handled by the same underlying flow. The system can decide how to inspect the file, extract the relevant contents items, clean the rows, and return structured data that can be reviewed and used inside the claim.

It turns document importing from a brittle conversion step into a more intelligent claims workflow.

Most importantly, this allows for people to do what they’re always going to do: upload whatever files they want.