Why the Same Question Has Two Answers

In one line

Insurance data has two time axes — the state as of when (the as-of date) and computed from facts known as of when (the known-as-of date). A report that records only one of the two cannot be reproduced next month.

Why this was needed

We sent off the June close report saying "10 lapsed policies." In August, running the same query again for audit response gave 7. The query had been saved as a file and not a single character was changed. The as-of date is also the same, 2026-06-30.

There is nothing you can say in this spot. To the audit team it sounds like "I don't know why the number changed," and the next question is always "then what was the number you sent in June?"

The cause is neither data contamination nor a bug. It is because insurance often rewrites the past.

How it works

There are several paths by which the past gets rewritten.

수납 누락 정정   창구에서 받은 보험료가 원장에 안 실렸다가 민원 뒤 소급 입력
계약 정정        가입 나이·직업·피보험자 정보를 잘못 받아 소급해서 바로잡음
소급 담보        특약 개시일을 계약일로 되돌려 그 사이 사고까지 보장
심사 번복        부지급했던 건이 이의에서 뒤집혀 지급으로 정정

All of them are entered today but take effect in the past. So the phrase "as of 2026-06-30" alone does not pin down a single answer. You need one more thing.

기준일(as-of date)      어느 날의 상태를 묻는가
인지일(known-as-of)     언제까지 알게 된 사실로 계산하는가

A retroactive correction that came in on July 5 changes the state on June 30. It is a fact that did not exist when you computed on June 30, and it is a fact that exists when you compute on August 31. The as-of date is the same, but the answer differs. A design that holds two time axes like this is called bitemporal.

So which is the right answer? Both are right. They are simply used differently.

그때 조회한 값   그날 보낸 리포트가 왜 그 숫자였는지 설명할 때
지금 조회한 값   지금 무엇을 해야 하는지 정할 때

Audit asks the former and operations uses the latter. If you cannot tell the two apart, you cannot explain in an audit, and if you tell them apart but do not keep them, you have nothing to base the explanation on.

That is why a close report stores the result, not the query. If you store only the query, running it next time gives a different answer, and there is no way to tell whether the difference is due to a correction or an incident. If you leave a snapshot with both the as-of date and the known-as-of date written on it, "this is what it came out as then" becomes a provable fact.

One more thing. You must not erase the correction history. A design that overwrites values and throws away the old ones makes it impossible, from that moment on, to ever restore "the value looked up then." One table that keeps the old value and the correction time cuts months of disputes later.

What it looks like in the field

First, a client whose month-end reconciliation is off every month usually has this problem underneath. Accounting uses the number fixed at close time while the ledger lookup uses the current value, and retroactive corrections come in between. The two numbers differing is not a bug but a design, and what needs fixing is not the number but the report that did not write "as of which point in time."

Second, when you get a report saying "why is the number different from yesterday," you look at the correction history first. Recounting the data or suspecting the join comes after that. If you switch the order, half a day is gone.

Third, the habit of writing only the as-of date in a report and not the known-as-of date looks fine with no problems and then blows up once, big, at audit time. Usually nobody asks, so no signal comes that it is wrong.

What you will do in the next lab

You run the same query with two as-of dates and reproduce the lapsed count rising from 7 to 12. Then, holding the as-of date fixed and changing only the known-as-of date, you see the answer for the same 2026-06-30 split into 10 and 7. You prove, down to the policy numbers, that the difference of 3 is not an incident but due to the payment-receipt correction that came in on July 5, and at the end you build a reproducible snapshot table.