What Should You Measure When Payment Is Reported as Late

In one line

A payment delay cannot be fixed as one lump of time, and only when you split it into segments does a place to fix appear, and since the mean hides the tail, the people who file complaints are not in the mean.

Why this was needed

You get a report that "claim payment is too slow." When you open the dashboard, the mean processing time reads 4.8 days, within the 7-day target. On the metric there is no problem at all.

Yet complaints keep coming in. Naturally. The people who file complaints are not the people at the mean. They are on the side that has been waiting for 25 days, and the mean is low because there are many short cases, not because there are no long ones.

How it works

A claim passes through these stages.

접수 → 조사 → 심사 → 지급 / 부지급 → (이의)

Intake is the point at which the customer submitted documents. Investigation is the stage that checks whether the accident really happened and whether it is within the policy terms' coverage, and only the cases that need it go there. Checking hospital records or a site investigation falls here. Review is the stage that decides whether to pay and how much, and payment is the stage where money actually goes out.

To catch delays, you have to measure the time between these stages separately. If you say only "20 days from intake to payment" as one lump, there is no place to fix. Only when it is split and "18 days in investigation" comes out does someone say let's fix the investigation assignment rules.

And you look at percentiles instead of the mean.

평균     짧은 건이 끌어내린다. 목표 달성으로 보이게 만든다
p50      절반의 사람이 겪는 시간
p90      열에 하나가 겪는 시간. 민원이 여기서 나온다
p99      최악의 백 분의 하나. 언론과 감독기관이 여기를 본다

When reporting a delay, you must separate whether the delay is due to the system or due to review. If the stretch from intake to investigation assignment is long, it is a staffing or assignment problem, and if the stretch from payment decision to actual transfer is long, it is a system or settlement cycle problem. If you report only "payment is slow" without this distinction, the client throws the work to the development team, and the development team digs where there is nothing to fix.

A denial comes with a reason code. Things like an accident within the waiting period, breach of the pre-contract duty of disclosure, an exclusion in the policy terms, and a diagnosis outside the covered range. There is one misuse that comes up often here — using incomplete documents as a reason for denial. If documents are lacking, you should request additional documents, not refuse payment. Cases handled this way are almost all overturned on appeal, and an overturned denial is not a statistic but an incident. The customer spent months without receiving money they were owed.

If payment is late, interest accrues. The standard terms set a payment due date, and past that date you must add late-payment interest for the number of days exceeded. The amount per case is on the order of a few thousand won, so it looks small, but two things are a problem. Collected company-wide, the amount becomes large, and above all the number of late cases itself becomes an inspection finding.

Here is one rule about amount calculation. Insurance amounts are handled as integer won from start to finish. If you compute in floating point, reconciliation is off by one won each time because 0.1 + 0.2 is not 0.3, and finding the cause of that one won takes days. If you need division, do all the multiplications first and divide only once at the end.

What it looks like in the field

First, the stage table and the ledger not matching is common. A few cases remain in which the stage history is stamped as review finished but no decision has entered the claims ledger. Those customers are waiting without receiving any notice. Counting the same number in two places is the fastest way to find such cases.

Second, if you send a delay report with only the mean, nothing happens. That is because the reader reads it as "no problem." You have to put p90 and p99 side by side and even write in which segment that time came from, for a decision to be made at the next meeting.

Third, the distribution of denial reason codes gains meaning only when seen together with the number overturned. Looking only at counts per code, it is spread evenly and looks normal, but if the overturns are concentrated in one code, that is not a statistic but a defect in the review rules.

Where the data goes out of line in a claims system

When moving the claims flow into a system, what is hard is not the rules but state and time. There are three things seen repeatedly in the field.

The same claim comes in several times. It is common for one to come in through the app, one by fax, and one at a branch. To a person it is the same case, but the system receives them as separate ones. If at the intake stage there is no screen that groups and shows duplicate candidates, a double payment is found after payment. You pick candidates by policy number, accident date, disease code, and claim amount, and a person makes the judgment.

A request for additional documents turns the state back. If it is sent back for lacking documents, the claim returns to the pre-review state. How to count the processing deadline at that point must be defined. Late-payment interest and complaints split depending on whether the clock stops or keeps running. A transition that turns the state back must always leave its reason and time.

The amount changes several times. The claimed amount, reviewed amount, decided amount, and paid amount are all different, and denials, partial payments, and additional payments get attached afterward. If you build it to update a single amount field, you cannot answer "why did this amount come out?" Accumulate amounts as a history and compute the current value.

Put payment failure into the flow. It always happens that a transfer is returned because the account is wrong. If you treat payment as "the end," the case disappears from the system and only the customer waits. There must be returned and re-paid states after payment too.

Use review automation for passing first, not for declining. If you automatically pass small claims that clearly should be paid, people can concentrate on the hard cases. Conversely, if you put in automatic declines first, the cost when it is wrong is far higher, and you also take on the burden of explaining why that judgment came out.

What you will do in the next lab

You build 200 claims and the stage history and split the time from intake to payment into four segments. You expose the p90 of 389 hours and p99 of 609 hours hidden behind the mean of 116 hours, and pinpoint with numbers that 95% of the time of the 17 tail cases came from the investigation segment. You count the reason codes of the 30 denials to find that the overturns are concentrated in one code, and compute the late-payment interest as integer won.