Why Review the Whole Payment Process?
A claims payment can be correct at the point of adjudication and still be wrong when it reaches a claimant. A payment file may contain a transposed amount, an unauthorized change in bank details, or a duplicate instruction. Reviewing only the claim decision misses errors introduced in later handoffs. A useful control review therefore traces a payment from authorization through settlement and considers what happens when an error is detected.
The review is not simply a list of controls. It asks whether the controls cover the important risks, whether their design could prevent or detect the relevant errors, whether evidence shows they operated as intended, and what exposure remains. The examples below use hypothetical insurers and claims; their data are illustrative, not industry statistics.
Map the Transaction Before Judging the Controls
Begin with the payment’s path, not with a preselected control checklist. A typical hypothetical process may include claim adjudication, authorization, entry into a payment system, creation of a payment file, treasury release, bank settlement, reconciliation, and correction or recovery. At each handoff, identify who performs the step, what information is used, what could go wrong, and what evidence should remain.
Controls are commonly described by their main purpose. A preventive control aims to stop an error or unauthorized action before it causes a payment. A detective control aims to identify an error after it occurs, ideally before settlement or before it remains uncorrected. A corrective control responds to a detected problem, for example by stopping a payment, recovering funds, correcting a record, or addressing the cause. One control may serve more than one purpose, but its actual operation determines what it accomplishes.
- Authorization: Is the payment supported by an approved claim decision and within the approver’s authority?
- Payment preparation: Are the amount and recipient details transferred accurately, and are changes appropriately restricted and reviewed?
- Release: Does an authorized person approve the actual payment file, including its amount and payees?
- Reconciliation: Is the amount settled by the bank compared with the authorized file, and are differences investigated?
- Correction: Are errors stopped or recovered, documented, and considered for process improvements?
A process map should distinguish the intended design from the actual path taken by a particular payment. A control description such as “the payment is reviewed” is incomplete unless the reviewer, timing, information reviewed, decision criteria, and retained evidence are clear.
Design, Operation, Evidence, and Gaps
A well-designed control must address a specified risk at a point where it can still make a difference. For example, a review of a payment file may be designed to catch an incorrect amount only if the reviewer compares the file amount with an independently established approved amount. A review that merely confirms that a file exists does not address amount accuracy, even if it is performed every day.
Operating evidence should support what the control is said to do. A sign-off can show that a review was recorded, but may not show what was reviewed or whether exceptions were resolved. Useful evidence may include a time-stamped approval, the relevant comparison, an exception log, and documentation of follow-up. The reviewer should also consider whether the evidence covers the relevant population and period; a few selected records do not, by themselves, demonstrate that every payment was reviewed.
State the possible error, such as an unauthorized or inaccurate payment, and identify where it can enter the process.
Specify the performer, timing, information compared, approval criteria, and required response. Decide whether those features could address the risk.
Check whether the control was performed for the relevant transactions and period, and whether exceptions were investigated and resolved.
Describe errors the control might not catch, failures in its performance, dependence on another control, and any unresolved or unrecovered payment.
Worked Reviews of a Claims Payment
Worked Example: Trace an Amount Error Through Settlement
A hypothetical insurer approves a covered claim for $8,460. The payment system should send $8,460 to the authorized claimant. A staff member enters $8,640 into a payment file. A second employee approves the file, the bank settles it, and a monthly reconciliation compares the bank statement with the payment-system total but does not compare either amount with the approved claim record. Trace the error and assess the controls.
Method. Follow the transaction in order, identify what each control actually compares, and distinguish the occurrence of a control from its relevance to this error.
1. Authorization. The claim decision supports a payment of $8,460. This establishes the authorized amount but does not, on its own, ensure that the payment file contains that amount.
2. File preparation and approval. The entered amount is $8,640, which is $180 more than authorized: $8,640 − $8,460 = $180. A second-person approval could be preventive if the approver compares the payment amount with the approved claim record before release. The scenario does not say that comparison occurs. Merely having a second approver is not enough to conclude that the amount error would be stopped.
3. Settlement and reconciliation. The bank settles $8,640. The stated reconciliation compares the bank statement with the payment-system total. Both may show $8,640, so they agree even though the payment exceeds the authorization by $180. This reconciliation may help detect differences between the bank and the payment system, but its design does not address the authorization-to-payment mismatch.
4. Remaining gap. The process lacks a described control that compares the actual payment instruction with the approved claim amount. A suitable control could require the release approver to compare those records and stop the file if they differ. A reconciliation could also include that comparison, but it would be detective after settlement unless it is completed before release.
Check. The overpayment is $180, and the bank-to-system reconciliation does not identify it because both records contain $8,640. The common mistake avoided is treating any reconciliation or second approval as effective for every type of error, regardless of what information is compared.
Worked Example: Interpret Exceptions in a Control Test
A hypothetical insurer requires a supervisor to approve every manual change to a claimant’s bank details before the next payment is released. The control is intended to reduce unauthorized changes. For one review period, a tester selects 25 changes from a complete system-generated population. In 23 cases, dated supervisor approval is present before payment. In one case, approval is dated after payment. In another, the file contains a supervisor’s initials but no evidence of what was reviewed or when. Assess the control and its evidence.
Method. First assess whether the stated control could address the risk; then count and characterize the exceptions in the tested items. Do not treat a sample result as proof about every item in the population.
1. Design. Requiring approval before the next payment is released can address the risk if the supervisor verifies the legitimacy of the change and the payment process blocks release until approval. The description does not establish that the system enforces the block, so that feature would need to be confirmed. Approval after payment does not meet the stated timing requirement.
2. Evidence and exceptions. Of the 25 tested changes, 23 have approval evidence dated before payment. One is late, and one has initials without evidence of timing or review content. Thus, 2 of 25 items are exceptions to the evidence requirement. The observed exception fraction is \(2/25=0.08\), or 8%.
3. Conclusion. The 23 supported items provide evidence that the control operated as specified for those tested transactions. The late approval is a timing exception; the initials-only item does not establish that the required review occurred before payment. The 8% is a description of this sample, not a demonstrated population failure rate. The reviewer should investigate both exceptions, consider their causes and potential impact, and determine whether broader testing or other evidence is needed.
Check. The two exceptions are not equivalent: one documents a review that was too late, while the other does not establish when or what review occurred. The common mistake avoided is concluding that the control operated effectively merely because 23 of 25 files contain some evidence, without considering the control’s timing requirement and the limitations of the sample.
Worked Example: Quantify What a Layered Review Leaves Behind
In a hypothetical payment run, 20 instructions are later confirmed to contain an error that would cause a $500 overpayment if settled. A pre-release validation rejects 15 of these instructions. The remaining instructions settle. A next-day reconciliation identifies 4 of the settled erroneous payments, and the recovery team successfully recovers 3 of those 4 overpayments before the review period ends. Assume the counts refer to distinct instructions and each error has the same $500 overpayment. Trace the controls and calculate the unresolved exposure at period end.
Method. Apply each control to the items that reach it, then distinguish errors detected from funds actually recovered.
1. Preventive control. The validation rejects 15 of the 20 erroneous instructions. The number that passes validation is \(20-15=5\). The observed prevention fraction among these known erroneous instructions is \(15/20=0.75\), or 75%.
2. Detective control. All 5 that passed validation settle. Reconciliation identifies 4, leaving \(5-4=1\) erroneous payment undetected at this stage. The reconciliation therefore detects 4 of the 5 settled errors in this scenario; it does not prevent their initial settlement.
3. Corrective action. The recovery team obtains funds for 3 of the 4 detected overpayments. One detected overpayment remains unrecovered, and the one undetected error also remains unresolved. Therefore, 2 overpayments remain outstanding.
4. Exposure calculation and check. At $500 each, the unresolved amount is \(2 \times \$500=\$1{,}000\). Equivalently, 20 errors began in the scenario; 15 were rejected, 3 settled overpayments were recovered, and \(20-15-3=2\) remain unresolved. The result is $1,000, not the $500 associated with only the detected-but-unrecovered item.
The common mistake avoided is treating detection as if it automatically recovers a payment. The example also shows why the review should report both the errors that passed controls and the funds recovered, rather than describing the reconciliation alone as complete mitigation.
Why Layered Controls Need Careful Interpretation
Several controls can address different stages of the same payment, but their effects should not be added as though each operates on the original error population. A pre-release check acts on instructions before settlement; a reconciliation acts on transactions that have already settled; recovery acts only on identified losses. The sequence matters.
A simple derivation makes this explicit. Suppose \(N_0\) erroneous instructions enter a process. Let \(b_1\) be the fraction of those errors blocked by the first control. The number reaching the next stage is \(N_1=N_0(1-b_1)\). If the next control detects a fraction \(b_2\) of the errors that reach it, then the number passing both controls is
This multiplication follows because the second fraction is applied to the errors remaining after the first control, not to the original total. The expression is appropriate when \(b_1\) and \(b_2\) describe the actual sequential fractions for the population being assessed. It is not a license to multiply estimated control effectiveness percentages without support. In particular, a test exception rate is not automatically a control failure probability, and a control may not address every error type.
A review should also consider whether controls share a vulnerability. For example, two approvals may both rely on the same inaccurate claim record. Their presence does not provide two independent checks of the underlying amount. State the dependency plainly: what information each control uses, who performs it, and whether one failure could undermine the others.
Common Mistakes and Review Conclusions
- Stopping at claim approval. Authorization does not prove that the amount and recipient in the payment file are correct.
- Confusing a control label with its purpose. A “reconciliation” is not necessarily a control over authorization; identify the records actually compared.
- Accepting a sign-off without relevant evidence. A name or set of initials may not show timing, review scope, or resolution of an exception.
- Equating detection with prevention or recovery. A post-settlement match may identify a problem only after funds have left the insurer; a further action is needed to stop or recover payment.
- Overstating what a sample establishes. Report the tested items and exceptions accurately, and do not present the sample fraction as a proven population rate.
A useful conclusion is specific rather than absolute. It names the risk, the relevant control, the evidence reviewed, the exceptions, and the remaining gap. For example: “The release review is designed to compare payment amounts with approved claims, but the two exceptions lacked evidence of a timely comparison; therefore, the review does not establish that all tested payments were checked as required, and the exposure from unsupported payments remains to be assessed.” This is more informative than saying only that “controls are in place.”
Check Your Understanding
For each hypothetical situation, identify the control purpose and the most important conclusion or calculation.
- A payment is authorized for $3,275, but the file contains $3,725. The release reviewer compares the file only with the bank’s total after settlement. What is the amount error, and does this comparison address it? (Answer: $450 overpayment; no, it compares settled funds with the bank total rather than the approved claim amount.)
- A sample of 40 manual payment changes contains 36 files with dated pre-release approval, 3 with approval after release, and 1 with no approval evidence. How many exceptions are present, and what is the sample exception fraction? (Answer: 4 exceptions; \(4/40=0.10\), or 10%, in the sample.)
- A preventive check rejects 12 of 16 erroneous instructions. A later reconciliation identifies 3 of the 4 that passed. How many erroneous instructions remain undetected after reconciliation? (Answer: 1.)
- Of the 3 errors identified in Question 3, the recovery team recovers two payments of $240 each. Each undetected or unrecovered error is $240. What amount remains unresolved across all errors? (Answer: 2 errors remain unresolved, for \(2\times \$240=\$480\).)
- A supervisor signs off on bank-detail changes, but the review uses only a daily list of changed accounts and not the supporting authorization. What design gap should the reviewer state? (Answer: The sign-off alone does not establish that the changes were legitimate; the control needs a documented comparison with appropriate authorization before payment.)