All Totals Balanced and the Run Was Still Wrong
An edit program processes an 18,442-record adjustment file and passes 18,440 records to the master update. The run's control report shows records read 18,442, records rejected 2, records passed 18,440, input amount total $1,284,930.17, passed amount total $1,284,930.17, input hash total of account numbers 9,447,102,558, and passed hash total 9,447,102,558. The two rejects carry reason code AMT=0.00 and amount $0.00. The operator signs off because every total balances. An auditor objects on two grounds: the two rejected entries are legitimate zero-amount adjustments that other departments use to close suspense items, and the file's control standard requires every input record to land in exactly one destination (master, suspense, or reject) with a reconciling count, and requires hash totals to be computed over the post-edit file only. In fact the programmer's hash routine accumulates the account number as each record is read and never subtracts rejects.
1. Explain how two legitimate records can be dropped while every reported total balances. Identify which control actually failed.
Read the worked answer
Three separate reasons the report looks clean:
- Amount total: the two records are $0.00, so removing them cannot change the dollar total. The amount control is structurally blind to this class of record.
- Hash total: the routine accumulates the account number on read, before the accept/reject decision, and never backs out a rejected record. The passed hash total therefore equals the input hash total by construction; it is not a control over the output at all, it is a copy of the input.
- Count: read 18,442 = passed 18,440 + rejected 2. The equation balances because the rejects are accounted for, not because they were correct rejects.
The control that failed is the business-rule control, not arithmetic. No step compared the reject reason codes against the set of permitted reject reasons, so a rule that treats zero amount as invalid ran unopposed. Every total balancing tells you the arithmetic is internally consistent; it says nothing about whether the right records were rejected.
2. Specify the controls that would have caught this before sign-off.
Read the worked answer
- Reason-code edit: each reject reason must appear on an approved list. AMT=0.00 should not be on it, because zero-amount adjustments are valid in this file. An unapproved reason halts the run.
- Reason-code distribution report: show count and dollar value per reason for every run. A reason that fires two times and has never fired before is visible on the report even if someone forgets to compare it to a list.
- Hash total computed after the edit decision, over the passed file only, with rejects and suspense explicitly subtracted. As written, the hash proves nothing.
- Three-way reconciliation on the report: read = passed + rejected + suspense, printed as a check line rather than left to the reader.
- Zero-amount record policy documented and tested: the acceptance test file must contain zero-amount adjustments, since a test file of ordinary positive amounts will never exercise the rule.
3. Should the operator certify the run? Recommend the remediation and the risk to manage.
Read the worked answer
Do not certify. The records were not lost in a technical sense; they were removed by a business rule that should not exist. But the effect is the same: two suspense items stay open, the departments relying on them are misinformed, and the sign-off asserts a correctness that the evidence does not support.
Remediation:
- Copy the two records from the reject file into the suspense file with a reference to the original run, so the destination equation holds.
- Correct the edit rule so zero-amount adjustments pass or go to suspense, never to reject.
- Re-run only the correction; do not re-run the whole 18,442-record file.
The risk to manage is double-processing. If the master update already applied any part of this run, re-running the file posts everything twice. Before remediation, confirm whether the update committed and whether it is restartable at record level. If it is not, post only the two records through a controlled one-off adjustment with its own reference number, and reconcile them back to the original reject list so the audit trail shows exactly what was done and why.