By Brian Lawing, EVP of Sales, Upstage AI
Overview: Studio reads FNOLs and police reports, including handwritten documents, and extracts structured data in under three seconds, with every field traceable to its source.
Every police department writes reports differently: some arrive as clean PDFs, some are handwritten and rough. The FNOL (first notice of loss), the report that kicks off every claim, is just as inconsistent. Some follow ACORD, the standardized insurance forms used industry wide, to collect and share claim and policy information, while others are in-house templates.
Nothing looks the same, but the task is identical every time: before anyone can assess a claim, someone has to read the full file and pull the claimant's name, the assigned adjuster, the policy type, the loss description, the injuries, who was involved, and what happened—then key all of it into the claims system before the real work begins.
None of this is hard, exactly. Your adjusters know how to read a police report and an FNOL. But they're spending the front half of every claim doing something that claims automation (the use of AI to read, extract, and structure claim data so adjusters don’t have to key it in by hand) should be doing for them… while the claimant waits and the clock on cycle time keeps running.
Industry-wide, J.D. Power puts the average time from first notice of loss to final payment at 40.7 days. Teams handling dozens of claims a day lose entire workdays to data entry instead of investigating the loss, assessing liability, and setting reserves.
What Studio does with a claim file
Upstage Studio automates claims intake using prebuilt AI agents that read, extract, and structure data from FNOLs, police reports, and the rest of your claim documents. No coding required, no heavy system implementation.
Here's what happens:
- Studio accepts any document, in any format. Your team drops the claim file into Studio: the FNOL, the police reports, mixed document types and all.
- Studio reads everything, even handwriting. This is where most intake tools fall down. Studio reads a handwritten police report with the same accuracy as a clean digital form, including sloppy handwriting, scanned pages, in-house templates, and pulls out the fields your team cares about.
- Studio traces every field back to its source. Your team can click into any extracted field and see exactly where on the document it came from. The state reads Texas, and the box it was pulled from is one click away. The officer badge number reads 87148, same thing. This "X-ray view" matters for one reason: audit trails. Values can be verified in seconds instead of digging through the original file.
- Studio adapts to your team's schema in plain language. The prebuilt extraction works out of the box for common claim documents. When something needs adjusting, your team fixes it with a sentence, not code. One police report listed the officer as "Off. R. Waters - 1054," mixing the title, name, and badge number together. A short instruction to ignore prefixes like "officer" and split out the badge number cleanly separated the fields.
- Studio surfaces, your adjuster decides. On a police report, Studio can flag where liability appears to sit; for example, noting that a driver who left the scene without stopping appears to be at fault. That's a starting point, not a verdict. Your adjuster makes the call. When a field has no answer, Studio leaves it empty rather than inventing one. An empty field you can trust is worth more than a confident wrong answer.
- Studio outputs data that your team can review and export. A table view puts every document side by side so your team can review field-level accuracy at a glance and correct only what needs correcting. When the data is ready, it can be pushed to your claims or policy admin system via an API or exported as JSON or Markdown, whatever fits your stack.
A two-page FNOL runs in under three seconds. Reading, extracting, and structuring the whole file takes minutes. What typically takes 15 to 20 minutes of reading and data entry becomes a quick review of clean, structured output.
Is Upstage Studio just OCR?
No. OCR converts an image into raw text, but it doesn’t know a badge number from a policy number. Studio uses AI models trained on insurance documents to identify and structure specific fields, links every extracted value back to its exact spot in the source file, and adapts its output to your team’s schema in plain language, none of which basic OCR can do.
What happens if a field can’t be read?
Studio returns an empty field instead of guessing, so your team always knows a value is verified rather than invented.
Why claims automation matters for your team
The time savings alone are significant. In Upstage’s work with Hanwha Life, claims automation delivered a 70% reduction in manual processing time.
- Faster response times. When adjusters aren't buried in data entry, they respond to claimants faster, move claims through the pipeline faster, and have time for the complex losses that need real judgment.
- Built-in audit trail. Because every field traces back to its source, you get an audit trail built in, not bolted on after the fact.
- Adjusters stay accountable. Because the system surfaces what it found and leaves the decision to a person, your adjusters stay accountable for the calls that matter. The machine reads, the human decides.
The same pattern holds across other insurance document types: cleaner extraction upstream means fewer manual entry errors and better data quality downstream, whichever workflow it feeds.
Claims automation shouldn't take the adjuster out of the loop. It should take the data entry out of the adjuster's day.
Try Studio on your own claim documents
Have a tricky FNOL or police report? Send it to our team and we’ll show you exactly how Studio reads it.
About the author
As EVP of Sales at Upstage AI, Brian Lawing works with insurance teams evaluating AI claims automation, document extraction, and FNOL intake workflows.


.png)



