AI Document Extraction Platform for Insurance Underwriting: Aggregation, Platforms, and What to Test (2026)

An underwriter does not receive one document. A commercial submission arrives as an email with an ACORD application, a statement of values (SOV), several years of loss runs, financial statements, and supplemental questionnaires, each in a different format from a different sender. An AI underwriting document extraction and aggregation platform reads those files, pulls out the fields underwriting needs, combines them into one record per risk, and hands that record to a rating engine, a workbench, or an underwriter.

That description hides three separate jobs, and vendors sell different combinations of them. This guide separates extraction, aggregation, and decision support, covers the documents that matter (including loss runs, SOVs, P&L statements, and policy documents), compares eleven named platforms, and sets out how to test accuracy and meet regulator expectations. The focus is property and casualty (P&C) underwriting, where submissions are document-heavy; life and health underwriting relies on different documents, such as medical records. How extraction turns a document into structured fields is covered in structured data extraction.

Who This Is For

Underwriting and operations leaders at carriers, MGAs, and wholesale brokers evaluating submission intake automation.
Insurtech product and engineering teams building intake or underwriting workbench features on top of an extraction API.
Data and portfolio teams that need clean exposure and loss data for pricing, accumulation, and catastrophe modelling.
Compliance and vendor management teams that have to document AI vendors under state insurance requirements.

Why Underwriting Teams Automate Intake

Underwriting time is the scarce resource. In Accenture's 2021 P&C Underwriting Survey, run with The Institutes, the average underwriter spent 40% of their time on administrative tasks and 30% on underwriting itself, with the remaining 30% going to negotiation and sales support. The survey is several years old, but the pattern it describes is the one intake automation targets: skilled people re-keying data before they can assess a risk.

The problem gets worse with volume. Submissions arrive by email, portal, and shared folder, and each broker formats them differently. Volume changes which parts of the pipeline break first, and scaling unstructured document processing covers those failure points in detail.

Extraction, Aggregation, and Decision Support Are Different Jobs

Buyers often compare platforms that do different things. Separating the jobs makes the comparison fair.

Extraction

Extraction reads a document and returns fields: the insured's name, a claim date, a location value, a revenue figure. Good extraction returns each value with its source (page and position), so a reviewer can check it. It does not decide whether the risk is acceptable.

Aggregation

Aggregation has two meanings in insurance, and the keyword is used for both.

Submission aggregation combines everything known about one risk into a single record. Fields from the ACORD application, rows from the SOV, claims from several loss runs, and figures from the financial statements are merged, and conflicts are resolved. When the application states one revenue figure and the P&L shows another, an aggregation layer surfaces the difference rather than picking one silently.

Exposure aggregation sums location-level values across a book of business for accumulation control and catastrophe modelling. It depends entirely on clean SOV data. In December 2024, Ping and ACORD Solutions Group announced a property SOV extraction and exposure solution that feeds extracted data into catastrophe models including RMS and AIR.

Decision Support

Decision support covers appetite checks, triage, rating, and recommendations. Platforms such as Kalepa, Sixfold, and Federato extend into this layer. It is valuable, but it is a different purchase from reading documents accurately, and a platform can be strong at one and thin at the other.

The Documents That Move Through Underwriting

ACORD Applications

The ACORD 125 commercial insurance application is the cover sheet of most commercial submissions. It collects applicant details, premises, general questions, prior carrier information, and loss history. Companion forms add line-specific detail: ACORD 126 for general liability, ACORD 140 for property, and ACORD 130 for workers' compensation. The same fields appear in different positions across form versions and across brokers' completed PDFs, and some arrive as scans.

ACORD Solutions Group itself offers ACORD Transcriber, an extraction tool that covers the full library of ACORD forms, which shows how central these forms are to the problem.

Statements of Values

An SOV lists every insured location with its values. A useful SOV carries the address, construction type, occupancy, year built, square footage, stories, roof type, protection status, and stated building and contents values. There is no standard format: submissions range from a clean single-sheet spreadsheet to thousands of locations across tabs with merged headers, or a PDF export of one.

The risk is silent error. A construction code mapped to the wrong class does not throw an error, but it misprices the location and corrupts the exposure data that feeds catastrophe models.

Loss Runs

A loss run is a carrier-issued history of claims, usually covering three to five years. It lists policy periods, claim numbers, dates of loss, amounts paid, reserves on open claims, and status. Every carrier uses its own layout and field names, so "amount paid" on one loss run may be "indemnity paid" on another.

Loss runs are often the messiest inputs: scans, faxed pages, and multi-page tables that break across pages. Scanned and degraded documents are where OCR and LLM-based approaches diverge most, as compared in LLMs vs OCR software. A good pipeline checks that claim lines add up to the stated totals, because a miskeyed reserve or status flows straight into pricing.

Financial Statements and P&L

Financial statements, including profit and loss (P&L) statements and balance sheets, support underwriting for financial lines and supply rating bases for others. Revenue and payroll are common exposure bases, so a misread figure can change the premium. P&L extraction has its own traps: multi-period columns, restated prior-year figures, subtotals that must reconcile with line items, and statements prepared in different formats by different accountants.

Policy Documents

Policy extraction covers declarations pages, endorsements, binders, and expiring policies. Underwriters need limits, deductibles, forms, and exclusions from an expiring policy to price a renewal or to compare an incumbent's terms with a new quote. These documents are long, dense, and full of references to forms, so extraction needs to capture both the values and where they came from.

Emails and Supplemental Applications

The email body often carries information that appears nowhere else: the requested effective date, the broker's notes, an inspection summary. Supplemental applications for specific classes of business add questionnaire-style fields. A platform that only reads attachments misses part of the submission.

Bordereaux

MGAs and coverholders send carriers periodic bordereaux, spreadsheet-style reports of premiums and claims. Formats differ by sender, so they need to be normalised before they can be compared or analysed.

How an Extraction and Aggregation Pipeline Works

A pipeline that survives production volume usually follows these steps:

Ingest and classify. Capture the email and attachments, assign a stable ID, and determine what each document is: ACORD form, SOV, loss run, financial statement, policy, or something unrecognised.
Split bundles. Separate multi-document PDFs into individual documents before extraction.
Extract against a schema. Pull the fields defined for each document type, with page and position for every value.
Validate. Check arithmetic and logic: claim lines against loss run totals, location values against the stated total insured value, P&L subtotals against line items, and dates against policy periods.
Reconcile across documents. Compare what the ACORD, SOV, loss runs, and financials say about the same risk and surface conflicts.
Route exceptions. Send low-confidence or conflicting fields to a person, with the reason attached, instead of passing them through.
Hand off. Write the aggregated record to the rating engine, workbench, policy system, or data warehouse.
Monitor. Track null rates, review volumes, and per-document-type accuracy so degradation shows up as an alert.

The overall shape matches the one described in intelligent document workflow automation. Step 5 is the one most often missing, and it is what separates aggregation from extraction.

From Extracted Data to Underwriting Analytics

Extraction is the first step toward analytics, and analytics inherit every error made upstream. Once fields are clean and aggregated, teams can calculate:

Frequency and severity by policy year from loss runs, plus open reserves and large-loss flags.
Loss ratio, which is incurred losses divided by earned premium, by account, class, or segment.
Financial ratios and trends from P&L statements and balance sheets, such as revenue growth and margins.
Total insured value by location, construction, and peril zone from SOVs, which feeds accumulation and catastrophe modelling.
Differences between expiring and proposed terms from policy documents.

The phrase "P&L" can also mean the insurer's own underwriting profit and loss by policy or segment. That view needs consistent premium and loss data, and the loss side depends on how reliably claims history was extracted in the first place.

How to Read Accuracy Claims

Published figures in this category are vendor-stated and rarely come with a method. Concirrus states 99% extraction accuracy for loss runs, IntellectAI cites 99.3% for its submission product, and Hyperscience says up to 99.5% on policyholder and claims data. None of those pages explains how the figure was measured or on which documents.

Ask four questions of any number:

What counts as correct? Character accuracy and field-level accuracy are different measures. One wrong digit in a policy number barely moves the first and ruins the second.
Which documents? A blended average across clean forms hides weak performance on faxed loss runs or irregular SOVs. Ask for results per document type.
Who built the ground truth? Vendor-run tests are not worthless, but you should be able to inspect the method.
What happens to the errors? A wrong field with no flag is worse than a flagged field. Ask whether uncertain values are marked in the API response, with a reason.

Straight-through rate and review burden decide whether automation pays off. The formulas for working that out are in metrics to measure the ROI of document workflow automation.

Evaluation Criteria Beyond Accuracy

Accuracy is one criterion among several. Comparisons of platforms in this category typically also weigh:

Training requirements: Some tools need templates or labelled examples for each document type, while others work from a schema you define. Ask how long a new document type takes to reach production accuracy.
Cross-document handling: Can the platform reconcile fields across the application, SOV, loss runs, and financials, or does it treat each file separately?
Source attribution: Does every value link back to a page and position?
Deployment and data handling: Cloud, private cloud, or on-premises options, data residency, retention, and whether your documents train the vendor's models.
Security evidence: Certifications and audit reports, stated on the vendor's own pages and confirmed in writing.
Integrations: Connections to policy administration, rating, workbench, and data warehouse systems, such as Guidewire or Duck Creek.
Human review tooling: How uncertain fields reach a reviewer, and whether the reason travels with them.

Platforms Compared

Descriptions below reflect each vendor's own pages, checked in October 2026. Most vendors in this category do not publish pricing, and the performance figures quoted are vendor-stated unless noted. Confirm current capabilities and terms directly before committing.

General-Purpose Extraction API

DeepRead

What it automates: A schema-driven extraction API. You define the fields for each document type, such as ACORD 125 applicant fields, loss run claim lines, or P&L line items, and it returns structured JSON. Each field comes with its page, bounding box, and source text, and uncertain values come back marked needs_review with a reason, so low-confidence fields arrive as a work queue. There are two products on one API key: Extract (the document as Markdown with layout blocks and bounding boxes, plus your fields as JSON) and Deep Extract (two OCR engines, adjudicated disagreements, and a verification pass, aimed at scans, photos, and handwriting).
Pricing: Free for 2,000 pages a month with no card, up to 50 pages per document and 15 MB per file, with both products included. Standard is pay per page with no monthly page limit, at $15 per 1,000 pages for Extract and $35 for Deep Extract, with documents up to 1,000 pages, webhooks, and no charge for a failed job. Enterprise is custom, adding documents up to 2,000 pages, retention controls, incognito processing, PII redaction, bring-your-own model keys, EU and AU data residency, SSO and SAML, and a custom SLA and MSA.
Limits: It is an extraction layer, not an underwriting platform, so appetite, rating, third-party data enrichment, and cross-document reconciliation are yours to build. It has no insurance-specific models. Its published benchmark is run by DeepRead itself and covers DocILE business documents, UK charity annual reports, and long PDFs with large tables, not ACORDs, SOVs, or loss runs.

Deep Extract averages 92.0% and Extract 91.1% there, against 89.9% for Extend Operator, with 2,614 pages per system. On the long-table set, Extend Operator scores higher (99.6% against 97.8%), which is the dataset closest to SOVs and multi-page loss runs. DeepRead reports $15 per 1,000 pages for Extract against $88 for Extend Operator, which it describes as 5.9x cheaper than the system ranked third on accuracy.

On data handling, DeepRead says processing and storage run in the US (US East) by default with no self-hosted option, and that Free and Standard keep documents for up to 3 years by default under its privacy policy, while Enterprise can set retention from 1 to 365 days or use incognito processing. It holds no ISO 27001 certification and does not offer a business associate agreement on any plan, which matters for life and health files, and insurers should weigh this in vendor due diligence.

Best for: Insurtech and carrier engineering teams building their own intake and aggregation layer that want citations, review flags, and transparent per-page pricing.
Pros: Published pricing and a free tier for testing on your own submissions, source citations on every field, review flags with reasons, and new document types defined by naming the fields instead of training a model.
Cons: You build the reconciliation, workflow, and underwriting logic yourself, and its benchmark does not include insurance documents.

Intake, Aggregation, and Underwriting Intelligence Platforms

Kalepa

What it automates: Classifies incoming submissions and extracts data from what it describes as hundreds of document types, including ACORDs, SOVs, loss runs, and supplemental applications. It enriches submissions with third-party and public data and presents a single view of exposures, loss runs, appetite fit, and referral guidance. Further modules cover clearance, triage, risk analysis, rating, quote and bind, and portfolio management.
Pricing: Not published; demo booking only.
Limits: Its page does not describe how extraction works or give per-document accuracy, and it names no specific security certifications. Its published results (for example a 58% reduction in quote time) are stated without a baseline or method.
Best for: Commercial and specialty carriers and MGAs that want intake, enrichment, and underwriting decision support in one platform.
Pros: Covers the full path from submission to quote and portfolio view, with third-party data enrichment included.
Cons: A broad platform is a larger commitment than an extraction layer, and extraction detail is thin on its public pages.

Cytora

What it automates: Risk digitisation across new business, renewals, claims, and mid-term adjustments. Its classifier matches each incoming request to the right schema, and digitisation actions include extraction, inference, entity resolution, and enrichment. Fields come with provenance, reasoning, and confidence scoring, and human review rules can be set against confidence thresholds. Output pre-populates downstream policy, CRM, and pricing systems.
Pricing: Not published.
Limits: Its page does not list the document types or file formats it supports. Its productivity results come from a customer quote (Markel: 38% fewer people in processing and 38% more cases handled) and are not independently measured.
Best for: Commercial insurers that want a configurable digitisation layer in front of existing policy and pricing systems.
Pros: Field-level provenance and configurable review rules, and its footer lists ISO 27001 and ISO 42001.
Cons: Public detail on supported documents is limited, and pricing requires a sales conversation.

Federato

What it automates: Ingests submissions and triages them against eligibility, appetite, and rating criteria, scores each against portfolio strategy, and generates a first-draft quote for underwriter review.
Pricing: Not published.
Limits: Its platform page does not describe document extraction, supported document types, or integrations in detail. The only timing claim is that a draft quote arrives within minutes.
Best for: Carriers that want appetite and portfolio-driven prioritisation of submissions.
Pros: Ties triage directly to underwriting appetite and portfolio view.
Cons: Better understood as an underwriting decision layer than a document extraction platform, so extraction depth needs to be tested separately.

Sixfold

What it automates: Its AI Underwriter for P&C insurers, launched in June 2026 according to launch coverage, extracts and cleans submission data, flags gaps, assesses appetite and portfolio fit, and gives a recommendation with a rationale and a suggested next step. It can be set up for straight-through processing. Each carrier gets its own model, which learns only from that carrier's decisions.
Pricing: Not published.
Limits: The launch coverage does not list the document types it ingests, and the capabilities described there come from the vendor's launch announcement rather than independent testing.
Best for: Carriers that want an agent-style underwriting assistant that recommends next steps.
Pros: Per-carrier models with a stated commitment not to train one carrier's model on another's data.
Cons: A newer P&C product, with limited public detail on extraction accuracy or document coverage.

Bevaya (formerly Roots)

What it automates: An AI agent platform for carriers, brokers, and TPAs covering underwriting, claims, and policy servicing. It is powered by InsurGPT, models the company says were trained on more than 300 million proprietary insurance documents, and integrates with Guidewire, Outlook, Slack, and Microsoft Teams. It includes human review tools and governance controls.
Pricing: Not published.
Limits: Bevaya replaced the Roots platform and brand in May 2026, so older Roots documentation and reviews may not match the current product. Its deployment and training-data figures are company statements.
Best for: Insurers that want pre-built agents across underwriting, claims, and servicing from one vendor.
Pros: Broad agent coverage and Guidewire integration, with a stated base of production deployments (more than 115, per the company).
Cons: A recent rebrand means less public track record under the new name, and loss run and extraction detail should be confirmed with the vendor.

Document Intelligence Platforms and Specialists

Instabase

What it automates: Ingests unstructured and structured underwriting documents, separates them into their parts, classifies them, extracts the data, and standardises it for analysis. It describes itself as a Guidewire Vanguard and connects to policy systems through an API.
Pricing: Not published.
Limits: Its underwriting page does not state deployment options, certifications beyond Guidewire Vanguard status, or accuracy figures.
Best for: Insurers with a wide mix of non-standard documents that want a general document intelligence platform.
Pros: Handles a broad range of document types and fits into Guidewire environments.
Cons: General-purpose breadth means insurance-specific logic (reconciliation, appetite) is something you configure.

Hyperscience

What it automates: Document processing for insurance, with documents including claims forms, applications, endorsements, medical records, certificates of insurance, and pre-built support for ACORD forms. It integrates with Guidewire InsuranceSuite, Duck Creek, Applied Epic, Sapiens, and Vertafore AMS360.
Pricing: Not published.
Limits: The 99.5% accuracy and 98% automation figures on its insurance page are stated as "up to" values without a method. It names no certifications on that page, and it lists a typical implementation of about 90 days.
Best for: Insurers that want a mature document processing platform with handwriting support and broad core-system integrations.
Pros: Pre-built ACORD support and wide integration coverage.
Cons: An implementation project measured in months, and no published pricing.

Concirrus

What it automates: Loss Run Intelligence converts loss runs from any carrier, as PDFs, spreadsheets, or images, into structured data. It validates totals and claim details, combines multiple loss runs for one insured, and outputs rating-ready CSV or API data into a rating engine or its Underwriting Workbench.
Pricing: Not published.
Limits: It states 99% extraction accuracy and 95% faster processing (complex files in under five minutes) without naming the baseline or the measurement method. It is focused on loss runs rather than the full submission.
Best for: Teams whose bottleneck is loss run intake for rating.
Pros: Purpose-built for the loss run problem, with total validation and multi-run consolidation.
Cons: Narrower than a full submission platform, so ACORDs, SOVs, and financials need another tool.

Ping

What it automates: PING.Extraction extracts and enriches data from SOVs, ACORDs, loss runs, and email bodies, then geocodes, validates, and enhances it. PING.Ready is a property data extraction service that combines machine learning with human support, and PING.CAT generates import files for catastrophe models or triggers cloud-based modelling. In December 2024, Ping and ACORD Solutions Group announced a property SOV extraction and exposure solution that feeds extracted data into models including RMS and AIR.
Pricing: Not listed; its site says you pay for the capabilities you need.
Limits: Its products page gives no accuracy figures, file formats, or policy system integrations, and its focus is property.
Best for: Property underwriters, MGAs, and brokers that need clean SOV and exposure data for catastrophe modelling.
Pros: Hands off directly to catastrophe models, adds property data enrichment, and states SOC 2 compliance on its site.
Cons: Property-centric, so casualty documents and full-submission reconciliation need other tools, and the human-support option means turnaround is not purely automated.

IntellectAI Magic Submission

What it automates: Submission ingestion and triage for commercial, specialty, and E&S lines, with human-in-the-loop review.
Pricing: Not published; demo request only.
Limits: The 99.3% extraction accuracy and 85% reduction in triage time are cited in its page description without a method. The page does not specify the document types handled or its integrations.
Best for: Commercial and specialty underwriters that want intake and triage automation.
Pros: Designed for commercial, specialty, and E&S submissions, with human-in-the-loop review.
Cons: Limited public detail on documents, integrations, and how accuracy was measured.

Quick Comparison

Need intake, enrichment, and decision support together: Kalepa, Cytora, Federato, Sixfold, and Bevaya sit in this group. Test how each handles your document mix, since extraction depth is described least clearly on public pages.
Need a general document intelligence platform: Instabase and Hyperscience cover many document types and connect to core systems.
Need loss runs specifically: Concirrus is built for them, with total validation and multi-run consolidation.
Need clean SOV and exposure data for catastrophe modelling: Ping is built around property SOVs and hands off to catastrophe models.
Need submission triage for commercial and specialty lines: IntellectAI Magic Submission targets that workflow.
Need an extraction API to build on: DeepRead offers published pricing from $15 per 1,000 pages, a free tier of 2,000 pages a month, and source citations with review flags, with the aggregation logic left to you.

What Regulators Expect When Insurers Use AI Vendors

Extraction is lower risk than automated decisioning, but vendor tools that touch underwriting inputs still sit inside the insurer’s governance. This is a summary, not legal advice.

The NAIC adopted its model bulletin on insurers’ use of AI systems on December 4, 2023. The NAIC’s adoption map showed 29 jurisdictions, including the District of Columbia and Puerto Rico, as of October 8, 2026. Insurers remain accountable for their third-party data and AI vendors, and their governance programs may include due diligence and, where appropriate, audit and cooperation terms in vendor contracts.

New York’s Insurance Circular Letter No. 7, issued on July 11, 2024, says insurers remain responsible for vendor-developed or vendor-deployed tools and cannot rely solely on a vendor’s claim of non-discrimination.

In practice, keep source citations and review decisions for each field, record the schema or model version behind each value, ask every vendor for documentation of intended use, testing, and data handling, and put audit and cooperation terms in contracts.

How to Run a Pilot

Assemble 50 to 100 real submissions, including the worst ones: faxed loss runs, SOVs with merged headers, and scanned ACORDs.
Key the correct values by hand for the fields that drive pricing. This is tedious and has no substitute.
Score at field level, per document type, not as a blended average.
Measure the review burden: how many fields or documents a person must touch, and how quickly.
Test the failure behaviour: a rotated page, a different document type, a corrupted file. Check that it fails loudly and that uncertain fields are flagged with a reason.
Test reconciliation: submissions where the ACORD, SOV, and financials disagree on purpose.
Review security and data handling: retention, residency, sub-processors, whether your documents train the vendor's models, and certifications. Get answers in writing.

Conclusion

An AI underwriting document extraction platform is only as useful as the aggregation and review logic around it. Separate the three jobs (extraction, aggregation, decision support), decide which you are buying, and test each on your own worst documents. Treat published accuracy figures as starting points rather than findings, weight review routing at least as heavily as headline accuracy, and keep source citations for everything that reaches a pricing decision.

FAQ

What is an AI underwriting document extraction platform?

It is software that reads the documents in an insurance submission, such as ACORD applications, SOVs, loss runs, financial statements, and policies, and turns them into structured fields that rating engines and underwriters can use. Many platforms also aggregate the fields into a single record per risk and add triage or decision support.

What is the difference between extraction and aggregation?

Extraction reads values from individual documents. Aggregation combines values from several documents and sources into one record per risk, reconciles conflicts, and can also mean summing location-level exposure across a portfolio for accumulation and catastrophe modelling.

Can AI extract loss runs accurately?

It can handle them at volume, but accuracy depends on the layout and scan quality. Vendors quote figures such as 99%, usually without a stated method. Test on your own worst loss runs, score at field level, and check that claim lines reconcile to the stated totals.

What is P&L extraction used for in underwriting?

Profit and loss statements supply revenue and other figures used for rating exposure bases and for assessing financial lines. Extraction needs to handle multi-period columns and restated figures, and it should validate that subtotals reconcile with line items.

What does policy extraction mean?

It means pulling limits, deductibles, forms, endorsements, and exclusions from declarations pages and policy documents, usually to price a renewal or compare an incumbent's terms with a new quote.

How much does an underwriting extraction platform cost?

Most underwriting platforms do not publish pricing. API-based tools publish per-page rates: DeepRead, for example, lists a free tier of 2,000 pages a month and paid use from $15 per 1,000 pages for Extract and $35 for Deep Extract. Model the full cost, including the review time for flagged fields.

Does DeepRead replace an underwriting platform?

No. It is a general-purpose extraction API that returns structured fields with citations and review flags. Appetite, rating, third-party data enrichment, and cross-document reconciliation are separate functions that you would build or buy elsewhere.

Do these platforms need training data for each document type?

It varies. Some tools need templates or labelled examples for each document type, while others work from a schema you define. Ask each vendor how long a new document type takes to reach production accuracy, and test it with a type you have not shown them before.

Are insurers responsible for the AI vendors they use?

Yes. The NAIC model bulletin expects insurers to remain accountable for third-party data and AI vendors, and New York's Insurance Circular Letter No. 7 states that insurers remain responsible for vendor-developed or vendor-deployed tools. Keep vendor documentation, testing records, and contract terms that support audits.