IBNR — incurred but not reported — is the gap between when care happens and when the plan finds out about it. A member has surgery on March 28. The hospital codes it, bills it, and routes it through a clearinghouse, and the 837 claim file lands in the plan’s queue in mid-May. The plan’s obligation was incurred in March. Its claims system doesn’t see a dollar of it until May.

Every plan is carrying some volume of that at any moment. On March 31, the paid-claims number for March is not what March actually cost — it is only what March cost that the plan has heard about so far. IBNR is the actuarial estimate of the rest.

Why the lag exists

Claims don’t arrive the day care is delivered, and the delay isn’t uniform. A retail pharmacy claim usually adjudicates in real time at the counter. A physician office visit might be submitted within a week. A complex inpatient stay can take months — the provider has to finish coding, the stay may be split across facilities, and a rejected submission has to be corrected and resubmitted, resetting the clock. Timely filing limits put an outer bound on it, but those are commonly 90 days to a year, so the tail is long.

Two related things are worth separating. IBNR proper is care delivered but never submitted yet. Some plans track a broader “incurred but not paid” figure that also picks up claims that have arrived but sit unadjudicated — pended for review, missing information, or awaiting prior authorization records. Both are money owed and not yet paid; only the first is invisible to the claims system.

Why a self-funded plan has to reserve for it

For a fully insured employer, none of this matters much — the carrier holds the risk and the reserve. For a self-funded plan, the money is the employer’s, and ignoring IBNR produces a specific and expensive mistake: the plan looks cheaper than it is, right up until the claims arrive.

This bites hardest at three moments. Financial statements — booking only paid claims understates plan liability, which is a real audit and accounting problem, not a presentation preference. Renewal and budgeting — setting next year’s contribution rates off an understated claims year builds the error into the following year’s funding. Plan termination or a change of administrator — when a plan ends or moves, claims for the old period keep arriving through the run-out window, and somebody has to have set money aside for them.

Aggregate stop-loss settlement runs into the same problem from the other direction: whether the plan crossed its attachment point depends on claims incurred in the year, not claims paid by December 31, so the final reconciliation waits on run-out to resolve the estimate into actual numbers.

How it gets estimated

The standard method is completion-factor development, sometimes called a lag triangle. The plan tabulates historical claims by the month care was incurred and the month it was paid, which shows how a typical incurred month fills in over time — say 55% of an incurred month’s eventual dollars are paid within 30 days, 85% by 60 days, 95% by 90 days. Apply that pattern in reverse to recent months, and the unpaid remainder is the IBNR estimate.

The method is only as good as its inputs, and it degrades in exactly the situations where a plan is most likely to need it: a young plan without enough history to build a stable triangle, a plan whose enrollment changed sharply, or a period when processing speed itself shifted — a claims backlog or a migration between administrators changes the payment pattern without changing the underlying medical cost at all, and a naive triangle will read that as a change in claims.

That last case is why a mid-year platform migration deserves attention. If accumulator balances and claims history don’t carry over cleanly, the lag pattern breaks and the reserve estimate breaks with it.

Where Claimaro fits

Claimaro does not produce certified IBNR reserves, and does not employ actuaries to sign them. A reserve that appears in an audited financial statement is actuarial work product, and it belongs with your actuary or a dedicated actuarial platform.

What the platform does is hold the data that estimate is built from, in the form the calculation actually needs: claims tagged with both date of service and date paid, so incurred-versus-paid development can be tabulated rather than reconstructed; complete claims history carried across a migration so the lag pattern stays intact; and claims, member, and enrollment report sets that export to CSV for your actuary’s own models. The forecasting engine and actuarial workbench use the same history for scenario modeling and claims projection — which answers the budgeting question next to the reserving one, without being a substitute for it.

← All glossary terms