COI Verification · reference

The ACORD 25 changed in December 2025. Here’s what it does to your parser.

One sentence added to the December 2025 edition changes what a number in the limits column means. It is not a layout change you can absorb by retraining a template — it changes the claim the document is making.

The sentence

ACORD 25 edition 2025/12 carries this in the certification box, above the coverages grid:

*LIMITS SHOWN MAY HAVE BEEN REDUCED BY PAID CLAIMS. LIMITS SHOWN ARE INCLUSIVE OF AMOUNTS REQUESTED BY THE CERTIFICATE HOLDER AND MAY NOT REFLECT POLICY LIMIT AMOUNTS IN EXCESS OF THOSE REQUESTED.

*Not Applicable in WY

Quoted from the form as filed — ACORD 25 (2025/12), © 1988–2025 ACORD Corporation — read from the New York Department of Financial Services’ approved-certificates library on 23 September 2026. The second sentence is the addition; the asterisk on the first and the Wyoming footnote came with it.

What it actually means

Before, a $1,000,000 in the EACH OCCURRENCE cell read as this policy carries a $1,000,000 per-occurrence limit.

After, it reads as at least $1,000,000.

The clause says the figure is inclusive of what the certificate holder asked for and may not reflect policy limits in excess of that request. A holder who requires $1,000,000 can receive a certificate showing $1,000,000 from an insured whose policy actually carries $5,000,000. Formally, on a 2025/12 certificate: 

shown_value  ≤  actual_policy_limit

The limits column became a floor, not a measurement.

The part that matters for a compliance check — and it is not the obvious part

The instinct is that this breaks compliance automation. For one specific shape of check it does not, and the reason is worth understanding before you audit your own code.

If every numeric rule you evaluate is a minimum, you are fine:

Your ruleCertificate showsActual limitCorrect verdict?
each_occurrence ≥ 1,000,000 1,000,000 ≥ 1,000,000 Yes — a pass is a real pass
each_occurrence ≥ 2,000,000 1,000,000 could be ≥ 2,000,000 Conservative — you may fail an adequate policy

Because the shown value is a floor and the test is shown ≥ required, a pass implies the real limit also clears the bar. The new clause cannot manufacture a clean verdict from an insufficient policy. What it can do is send you to ask a question about a policy that was fine all along, because the holder requested less than you require.

If any numeric rule you evaluate is an equality or a ceiling, re-read it today. “The limit must be exactly $1,000,000” and “the limit must not exceed $X” are both unanswerable from a 2025/12 certificate, because the document no longer claims to show the policy’s limit.

And if you compute a percentage, a score, or a gap size from the limits column, that number is now derived from a floor. It will read as precision it does not have.

Both editions are in circulation

The 2016/03 edition does not vanish. Certificates on the previous edition keep arriving for roughly a year after the new one was published, so a pipeline running today sees both. Two consequences for extraction:

  1. The coverages grid was reformatted. A parser keyed to fixed coordinates on the 2016/03 layout meets a different one and can silently misread rather than fail.
  2. The certification text differs between editions, which is what tells you which reading of the limits column applies. If you are not capturing the edition, you cannot know which you have.

What to check in your own pipeline

  1. Are your numeric rules all minimums? If yes, your verdicts survive this. Write down why.
  2. Do you capture the ACORD edition? If not, you cannot tell a floor from a figure.
  3. Does anything downstream treat an extracted limit as exact — a report, a score, a dashboard number, a stored “policy limit” field?
  4. Is your layout handling keyed to positions, or to labels? Positions break first.
  5. Do your test documents include a 2025/12 certificate at all?

What our COI API does, including what it does not do

Straight, because a page that audits other people’s pipelines should audit its own.

Every numeric requirement in our COI API is a minimum. There is one numeric limit comparison in the codebase and it tests actual < min. There is no equality rule and no ceiling rule. So a compliant verdict is a real pass under the 2025/12 clause — for the structural reason above, rather than because we did something clever.

We do not detect the ACORD edition. The response does not tell you whether the certificate you sent was 2016/03 or 2025/12, and a limit comes back as a bare number with no indication that on a 2025/12 form it is a floor. That is a real limitation, it is ours, and it belongs in the same paragraph as the good news.

We may report a deficiency that is not one — the conservative case in the table above. That is the direction we choose deliberately. The API returns cannot_determine as a verdict distinct from non-compliant, an evaluated list naming exactly which requirements were checked, and a withheld list naming every field it could not read. Telling you where to look beats telling you a number we cannot support.

What we have not done: tested anyone else’s engine against this change. The checklist above is what we would ask of any tool, including ours.

Related

What a certificate of insurance proves · Coverage requirements as data · COI Verification API

Last updated . Corrections: see About.