The ACORD 125 — the Commercial Insurance Application, Personal Lines section — arrives in the underwriting inbox as a PDF attachment. The information on that form is what the underwriter needs to produce a quote: the applicant's name and address, the nature of the business, the SIC or NAICS code, the coverage requested, the limits, and the prior loss history or loss runs attachment. In a policy-admin system built to receive structured data, that information is already in the right format. In most small-carrier environments, it is a PDF that someone reads and types from.
This is the submission triage problem. And the answer to it is not simply "automate the data entry" — the answer is a workflow design question about what happens to structured submission data after it enters the system, and whether the policy-admin infrastructure is built to use it.
The ACORD Form Family for Commercial Lines
ACORD produces a family of standardized forms used throughout the commercial lines submission and policy issuance process. The ones most relevant to carrier intake are:
- ACORD 125 — Commercial Insurance Application. The primary submission document for most commercial accounts. Captures insured information, business description, SIC/NAICS code, prior carrier information, and coverage section selections. Sections vary by coverage type requested.
- ACORD 126 — Commercial General Liability Section. Used in conjunction with ACORD 125 for GL coverage requests. Captures premises information, operations description, products/completed operations exposure, aggregate limits requested.
- ACORD 130 — Workers Compensation Application. Separate from the GL section; captures payroll by class code, number of employees, states of operation, prior workers' comp experience.
- ACORD 140 — Property Section. Used for commercial property coverage requests. Captures building values, construction type, occupancy, protection class, coverage form requested (replacement cost vs. actual cash value), and any exclusions.
A commercial account submission for a small manufacturer might include an ACORD 125, ACORD 126 (GL), ACORD 140 (property), and ACORD 130 (WC) — four separate forms with overlapping insured information and separate coverage-specific fields. Re-keying all four forms into a policy system is 45–90 minutes of data entry per submission, depending on complexity and the operator's familiarity with the form layout.
What "Parsing" Actually Does — and Doesn't Do
The term "ACORD form parsing" is used loosely in the market to describe everything from basic OCR (optical character recognition) that extracts text from a scanned PDF to fully structured form extraction that maps each field to its ACORD field number and returns a JSON object. The distinction matters because different parsing approaches have very different accuracy profiles and different integration requirements.
Basic OCR extracts text but does not understand form structure. The output is a block of text from which a human (or a secondary processing step) still has to identify which text corresponds to which field. That is useful for reducing the number of times someone has to toggle between a PDF and a data-entry form, but it is not structured data.
Structured form parsing — whether rule-based using template coordinates or model-based using form understanding — extracts data at the field level: Applicant Name, SIC Code, Premises - Street, GL Occurrence Limit Requested. ACORD forms have version-controlled field numbering. ACORD 125 Field 14 is the SIC code; ACORD 126 Field 46 is the General Aggregate Limit. A parsing system that understands ACORD field numbering can map extracted values directly to the correct fields in the policy-admin system, provided the policy-admin system is built to receive those fields by name.
We are not claiming that structured parsing eliminates data entry errors entirely. OCR extraction on handwritten sections of the form, non-standard agent modifications to the ACORD template, or poor scan quality all create extraction errors that require human review. The value of parsing is reducing the volume of keystrokes per submission, not achieving zero-error automation.
The Policy-Admin Readiness Problem
Here is the more important half of the problem that rarely gets addressed in discussions of ACORD parsing: parsing a form produces structured data, but that data has no value if the policy-admin system receiving it cannot use it. Most small-carrier policy systems — particularly legacy systems or heavily customized spreadsheet environments — have data fields that do not map cleanly to ACORD field definitions. The SIC code extracted from an ACORD 125 might need to be translated to an ISO GL class code before it can be used in the rating engine. The premises information from an ACORD 140 might need to be split across multiple fields in the property module. The payroll by class code from an ACORD 130 needs to map to the carrier's WC rate lookup table.
This translation layer — from ACORD field definition to the carrier's internal data model — is where ACORD parsing initiatives typically stall. The extraction accuracy is adequate; the policy system cannot consume the output. The result is that structured data gets extracted and then re-keyed anyway, because the underwriter has to look at the extracted values and manually enter them into a system that does not accept an API payload.
A growing commercial-lines carrier in Ohio writing a mix of BOP, GL, and commercial auto — roughly $22M in DWP and handling 400–500 new submissions per quarter — ran an ACORD parsing pilot in 2024. The extraction accuracy on printed ACORD forms was high. The failure point was that the carrier's policy system required manual entry of class codes into a coverage module that had no API endpoint. The parsed data had to be printed and used as a manual reference by the data-entry team rather than being ingested directly. The time savings were marginal — perhaps 20% reduction in entry time — not the 60–70% that structured ingestion would have delivered.
The lesson is that ACORD parsing is a downstream benefit of having a policy-admin system that accepts structured intake data. The parsing itself is the simpler part of the problem.
Submission Triage and the Appetite Question
Beyond data entry efficiency, structured ACORD intake enables a second workflow step that most small carriers handle informally: submission triage against underwriting appetite. Before an underwriter invests time in quoting a submission, the carrier needs to determine whether the risk is within appetite — the right LOB, the right geography, the right size of account, acceptable occupancy and class codes.
When submission intake is manual, triage is done by eyeball. An underwriter opens the PDF, scans the ACORD 125, and makes a judgment call about whether to quote or decline. That judgment is inconsistent — different underwriters apply different appetite thresholds, and there is no audit trail of why a particular submission was declined or deferred.
When submission intake is structured, triage rules can be applied programmatically at intake. The SIC code extracted from the ACORD 125 is checked against the carrier's appetite matrix: if the SIC code is on the carrier's written exclusion list (certain manufacturing classes, certain hazardous operations), the submission is flagged for declination review before it reaches an underwriter queue. If the requested GL limits exceed the carrier's per-policy maximum retention (before reinsurance), the submission is flagged for underwriter review rather than being routed to standard quoting.
This triage logic does not replace underwriter judgment — it is not making the declination decision. It is surfacing the relevant appetite flags at intake so the underwriter's time is spent on submissions that actually match what the carrier wants to write.
Loss Runs and the ACORD 125 Supplement
Commercial submissions typically include a loss run request along with the ACORD forms — a five-year history of claims from the prior carrier. Loss runs are not ACORD-standardized; they come in the prior carrier's own format. Parsing loss runs is a harder problem than parsing ACORD forms because there is no standard field layout to reference.
What a policy-admin system can do with loss runs at intake is limited to what a human review would do: capture the loss run attachment as a document against the submission record, note the number of claims and total incurred losses in a structured summary field, and flag submissions with loss frequency or severity outside acceptable ranges for underwriter review. The detailed loss analysis — evaluating individual claim types, looking for patterns in GL vs. property vs. auto losses — remains a judgment function.
The ACORD 125 does include a prior losses section (Field 135 and related fields) for a summary of prior losses. Structured extraction of that section — total number of claims, total losses incurred, largest single loss — can feed an intake triage rule without requiring the full loss run to be parsed.
What a Well-Designed Intake Workflow Looks Like
A submission intake workflow built around structured ACORD data has three stages. First, form extraction: the ACORD forms are parsed and the output is a structured payload of field values mapped to the carrier's data model. Second, intake validation: the system checks the structured data against completeness requirements (are all required fields populated?), appetite rules (is the SIC code and requested limit within the carrier's written appetite?), and duplicate submission detection (is this the same account submitted by two different agents?). Third, underwriter routing: submissions that pass intake validation are routed to the appropriate underwriter queue based on LOB, account size, and territory assignment.
This three-stage design reduces the average time from submission received to underwriter first look. More importantly, it ensures that the data the underwriter starts with — the class codes, limits, location information, prior loss summary — is already in the policy system rather than in a PDF attachment that needs to be re-keyed if the submission proceeds to quote.
Irys is built to receive structured ACORD intake data through its submission API. The data model maps ACORD field definitions to the policy record fields, including ISO GL class codes from the ACORD 125 SIC-to-class-code mapping, property values from ACORD 140, and payroll by class code from ACORD 130. When an ACORD-aware parser produces a structured output, Irys can ingest it directly — eliminating the re-keying step that turns parsing pilots into marginal wins rather than meaningful efficiency gains.