Extracting Coverage Limits and Deductibles From an Insurance Policy

Every limit in a policy is stated at least twice: once as a number on the declarations page and once as a rule in the coverage form that says what the number applies to. Extracting the number without the rule produces a value that is correct and useless.

The limit is stated in two places

A commercial policy assembled on Insurance Services Office forms — the standard forms most US carriers file, published by ISO, part of Verisk — has a declarations page carrying a table of dollar figures, and a coverage form carrying a section usually titled “Limits Of Insurance” that carries no dollar figures at all. The second section is the one that says the general aggregate is the most the insurer will pay for the sum of certain categories, that a per-occurrence limit is not increased by the number of claimants or claims, and that one limit sits inside another rather than beside it.

So the number and its semantics are separated by fifty pages, and endorsements can amend either. An extraction that reads only the declarations page returns a set of dollar amounts with no way to know that one of them caps another. An extraction that reads only the coverage form returns structure with no values. You need both, joined on the label text, and the labels are the join key precisely because they are printed identically in both places.

Four things that reduce a payment

These four are routinely collapsed into a single deductible field and they are four different operations. Getting them wrong is the most consequential error on this document, because each produces a different number from the same loss.

• Limit. A ceiling. The most the insurer pays. It does not change what a loss costs; it changes how much of it is transferred.
• Deductible. A retained amount subtracted from a covered loss before payment. It may be per occurrence, per claim, per location, or annual. A percentage deductible — common for wind and hail — is usually a percentage of the insured value of the affected property, not a percentage of the loss, so the same “2%” produces a completely different figure depending on which base the form specifies. Extract the base, not just the percentage.
• Sub-limit. A lower ceiling for a named category that sits inside a larger limit and does not add to it. A policy with a headline limit and a sub-limit for a specific peril pays at most the sub-limit for that peril, and paying it consumes the larger limit too. Modelled as a sibling field, a sub-limit reads as extra cover; modelled as a child, it reads correctly. This is the single most common structural mistake in a coverage schema.
• Self-insured retention. Not a deductible with a different name. The distinction that matters for extraction is that a retention typically sits below the insurer’s obligation entirely, with the insured handling the claim until it is exhausted, whereas a deductible normally sits inside a policy the insurer is already administering. Whether defence costs count toward exhausting it is stated in the form and is a separate boolean field.

Coinsurance is the fifth and it means two unrelated things. In a property policy, a coinsurance clause is an insurance-to-value requirement: if the amount of insurance carried is less than the stated percentage of the property’s value at the time of loss, the loss payment is reduced in proportion. The standard formula is the amount carried divided by the amount required (percentage times value), multiplied by the loss, then less the deductible, and capped at the limit. In a health plan, coinsurance is the share of an allowed amount the member pays after the deductible is met — a percentage of each bill, not a test on the amount of cover purchased. A schema that uses one coinsurance field for both is storing two different quantities under one name. See the health-plan sense as it appears on an explanation of benefits.

Per occurrence, aggregate, and the reset

A liability declarations page states several limits that are not alternatives to each other. There is typically a per-occurrence limit, a general aggregate for the policy period, a separate aggregate for products and completed operations, a personal and advertising injury limit, a limit for damage to premises rented to the insured, and a medical expense limit stated per person. Six numbers, five different bases.

The base is a field. Store each limit as an amount plus a basis enumeration — per occurrence, per claim, per person, per location, aggregate — plus the aggregate period where one applies, because an aggregate resets with the policy period and a policy extended by endorsement may or may not get a fresh one. That last point is why the aggregate cannot be read off the declarations page alone: the form states whether an extension of the policy period creates an additional aggregate, and it usually states that it does not.

Reading the declarations page

Declarations pages are tables rendered without table structure. The typical layout is a two-column leader-dotted list, sometimes with the dollar amounts right-aligned to a column that is not the same column on the second page. That produces three specific failures worth testing for:

• Row drift. A label on one line and its amount on the next, so the extraction pairs each amount with the label above it and every value shifts by one row. Catch it by asserting that the general aggregate is not smaller than the per-occurrence limit, which is true on ordinary commercial placements and false the moment the rows shift.
• The word “INCLUDED”. Where a coverage is provided at no separate charge or without a separate limit, the amount column carries a word rather than a number. Parsed numerically, it becomes null and reads as absent cover. Allow a string enumeration in the amount field.
• Continuation pages. Limits continue onto a second declarations page or a supplemental declarations page under a different header, and a per-page extraction that returns the first page’s object silently drops them. Reconcile the count of coverages against the schedule if the form provides one.

When the two disagree

It happens, and the honest answer for an extraction pipeline is that you do not resolve it in code. What you do is detect it, and detection is worth building because the disagreement is nearly always informative rather than an OCR error.

The usual cause is an endorsement. A change endorsement issued mid-term amends a limit, is appended to the policy PDF, and the original declarations page is still in the file above it showing the old number. Both numbers are genuinely printed in the document. Which one governs depends on the endorsement’s own effective date and on the form’s rules about amendment, which is a determination for the people whose job that is — not for the schema.

So model the output as a list of observations rather than a single value: each limit with the amount, the basis, the page it came from, the form number it appeared under, and the effective date of that form. Then flag any label with more than one distinct amount. A pipeline that emits one number per limit cannot represent the situation at all, and will pick one at random. A pipeline that emits three observations with a conflict flag has correctly extracted a policy that was amended, which is what the document says. The same reference-chain problem shows up more sharply in exclusions, which frequently are not in the policy body at all, and the general machinery for surfacing a conflict to a human lives in per-field confidence and review routing.