How does recomputing an amended schedule expose a hidden fault in a sample?

A data analyst at a reseller runs acceptance checks on a sample of insurance premium instalment schedules. The sample includes policy `POL-9034`, with 12 monthly premium instalments and a mid-term change of cover.

The analyst's script recomputes each schedule after the change. For `POL-9034`, the amendment `AMD-2216` raises the annual premium from 1,440.00 to 1,560.00 effective at month 5. The remaining seven instalment lines should carry the pro-rata uplift. The script finds that the new lines total 15.00 less than expected, and the closing balance is negative.

The analyst opens the linked records. The amendment shows `decision: approved`, yet the pro-rata flag is `false`, while the policy `PLC-31` says mid-term changes are charged pro-rata. The generator has produced an internal conflict between the policy and the outcome.

The analyst logs it as a defect with the three record identifiers, and asks the supplier to explain whether it is an intended exception or an error. The reseller holds the batch back from its catalogue until the answer arrives, and the sample tests are added to its standing acceptance suite.

**What it teaches:** cross-record recomputation catches faults that field-level validation misses. Every row can be well formed and the schedule still be wrong. Ask for identifiers that make it easy to trace a failing line back to its amendment and policy.