エラーを直す前に、なぜ出たかを残す。

請求と入金を照合していると、一件だけ顧客名が見つからない。マスタに名前を足せば、画面上のエラーは消えます。でも、そこで終わると次の月に同じ問題が戻ってくるかもしれません。

エラーは作業の邪魔に見えますが、データの流れを教えてくれる印でもあります。マスタへの登録が遅れたのか、古い顧客コードで入力したのか、別の取引を誤って紐づけたのか。原因によって直す場所が違います。表示だけを消す修正では、元の入力手順に残った問題が見えません。

まずは該当行を控え、どの条件でエラーになったかを残します。「請求IDは存在するが、顧客IDがマスタにない」「入金額はあるが、対応する請求IDがない」のように、事実だけを書きます。次に、入力、マスタ更新、データ取り込みのどこでズレたか仮説を置きます。この段階では、推測を原因と断定しないことが大切です。

確認が済んだら修正し、修正前と修正後を区別します。たとえば月末にマスタへ新規登録する運用なら、次回は登録の締切や入力時の警告を見直せるでしょう。一件のエラーが、繰り返すミスの予防につながります。

同じエラーが何度も出るなら、個別の修正だけでなく件数の推移も見ます。月ごとに「マスタ未登録が何件」「請求IDなしが何件」と並べれば、対策後に本当に減ったか確かめられます。対策したつもりでも件数が変わらなければ、直した場所が原因ではなかった可能性があります。記録を残すのは、過去を責めるためではなく、次のやり方を改善するためです。

記録の形は複雑でなくて構いません。「検出日／行ID／エラー種別／確認した事実／対応」の五列だけでも、同じ種類が増えているか見られます。未確認なら空欄のまま隠さず「未確認」と書く。仮に入力元の作業を変えても件数が減らなければ、その対策は効いていないと分かります。記録は対策の効果を確かめる材料です。月末に種類別の件数だけ見返せば、個別修正に追われている間には見えなかった傾向にも気づけます。

今日のルールは、エラーを消す前に「どの行が、どの条件で、いつ見つかったか」を残すこと。直した事実だけでなく、起きた理由をたどれる状態にします。