Start with the form and its edition
ACORD forms organize insurance information, but a form number alone does not define a reliable extraction schema. Identify the form, edition, page set, and any attached schedules before deciding which fields to request. A blank field, an unchecked box, and an illegible answer have different meanings for the person reviewing the packet.
Common intake examples include ACORD 25, a certificate of liability insurance; ACORD 125, the commercial insurance application; and ACORD 130, the workers compensation application. Their purposes differ, so test and configure them separately. Consult ACORD's forms resources for official forms and licensing. Cogneris does not supply licensed blank forms through this page or promise coverage of every form or edition.
Choose fields for the review task
- Certificate review — request the named insured, producer, insurer, policy identifiers, effective dates, listed limits, and certificate holder where the submitted form provides them.
- Commercial application intake — describe applicant details, business information, requested coverage, and references needed to associate schedules or supporting documents.
- Workers compensation intake — configure employer information, policy dates, locations, and the classification or payroll fields relevant to the review.
- Missing and ambiguous fields — establish how your application represents absent answers, unreadable handwriting, and conflicting dates. Preserve the original for resolution.
These are schema-design examples, not a fixed built-in response for every form. Use your own representative documents to establish which requested fields can be extracted acceptably. Source references and confidence depend on the returned output; a location is not guaranteed for every field.
A synthetic schema and result
A small certificate-intake schema might request namedInsured, policyNumber, and effectiveDate. The following shortened response fragment uses invented data and the documented extraction shape. It is not an ACORD form reproduction or proof of a policy's validity.
{
"data": {
"metadata": {
"namedInsured": { "value": "Example Workshop LLC", "confidence": 95 },
"policyNumber": { "value": "SYNTHETIC-1042", "confidence": 97 },
"effectiveDate": { "value": "2026-01-01", "confidence": 92 }
}
}
}Field names follow your tenant template. Extracted values are strings or null, and confidence uses a 0–100 scale. The full document extraction contract describes the service envelope and optional page and bounding-box locations. Validate dates and identifiers in your application before passing the record downstream.
Process insurance packets deliberately
An intake packet may combine an application, certificate, loss runs, endorsements, and supporting schedules. Classification can help your integration identify document types before selecting templates. Keep the packet-to-file relationship and check page completeness; do not assume that extraction automatically separates every mixed packet or resolves contradictions between documents.
Define cross-document comparisons in the integration scope. A reviewer may compare the extracted name and dates with another record, but the extraction result does not establish current coverage, authenticate a certificate, or make an underwriting decision. Configured manual review requires tenant enablement and agreed workflow phases; confidence alone does not route a field into review.
Validate before connecting an intake workflow
Evaluate by form and edition using digital PDFs, scans, handwriting, checkboxes, repeated sections, and missing pages. Review critical identifiers and dates separately from general text accuracy. Count unresolved fields and reviewer effort, and keep a held-out set for acceptance. See the OCR accuracy guide for measurement principles.
Start with the extraction API, quickstart, and operation pricing. For a wider journey, read the processing overview or discuss a configured document portal. Claims-specific input belongs in the related insurance claims extraction use case.