UATの参加を求められた経理に渡されるのは、たいてい伝票入力のテストケース一覧だ。取引先を選び、金額を入れ、転記する。想定どおりの仕訳が出たらOK欄にチェックを入れる。二週間かけて数百件を消化し、「経理部：合格」と署名する。そして稼働から三か月後、月次が締まらなくなる。ベンダーの単体テストが通っても経理が後で困るのは、1件の伝票が正しいかどうかではなく、積み上がった後に出てくるものだからだ。 残高、繰越、期間、集計、突合。どれも1伝票のテストでは絶対に姿を現さない。経理のUATは、操作の確認ではなく締めを1サイクル通す場として設計し直す必要がある。
単体テストが通っても、経理が困る理由
ベンダーが実施する単体テストと結合テストは、機能が仕様どおりに動くかを見る。1件の伝票を入れ、想定の勘定に転記されることを確認する。これは必要な工程で、ここを経理が重複してやる意味はほとんどない。
経理が詰まるのは、その先だ。伝票が数万件積み上がった状態で、月次の残高が前月から正しくつながるか。期間をクローズした後に修正が入ったとき、どちらの月に落ちるか。自動仕訳が想定外のマスタ組み合わせで別の勘定に飛んでいないか。サブシステムから来た数字と会計側の残高が一致するか。どれも「積み上げ」と「時間」が要る現象で、1件ずつのテストケースを何百件消化しても出てこない。
だから経理のUATで最初に決めるべきは、テストケースの数ではなく何サイクル回すかである。月次を1回だけ通したUATは、繰越の検証をしていないに等しい。最低でも2か月分、可能なら四半期の締めを含めて回す。
テストケースは、伝票でなく決算成果物から逆算する
範囲の決め方は、出口から入るのが唯一まともな方法だ。稼働後に経理が作らなければならないものを、先に全部並べる。
月次試算表と勘定明細。部門別・製品別のP/L。連結パッケージに入れる数字。開示注記のもとになるデータ。税務申告の別表と申告調整の材料。経営会議に出す資料。銀行に出す試算表。この一覧を作り、それぞれについて「どの項目が、どの粒度で必要か」を書き出す。そこから逆に辿って、各伝票にどの属性が入っていなければならないかを確認する。
この逆算を省くと、典型的な事故が起きる。伝票は正常に転記されるが、後から部門別に割れない。取引先別に集計できない。プロジェクト別の実績が出ない。原因は、分析軸が伝票に入っていないことだ。そして分析軸は後から遡って付けられない。稼働してから「この軸で見たい」と言っても、過去の伝票には入っていないので、その期は分解できないまま終わる（管理会計の分析軸（ディメンション）設計｜あとから分解できない粒度を先に決める）。
税務も同じ構造で見落とされやすい。交際費の区分、寄附金、減価償却の税務差異、貸倒引当の限度超過。申告調整に必要な情報が伝票や補助科目に落ちていないと、決算後に手作業で集計し直すことになる。UATの段階なら、勘定科目か補助情報の設計を直せる。稼働後に気づけば、毎期のExcel作業として固定する（税務申告と決算をつなぐ｜申告調整を期末に慌てて作らない期中の分担）。
粒度は「頻度」と「後戻りコスト」の2軸で決める
すべてを同じ厚さでテストしようとすると、限られた期間の中で全部が薄くなる。粒度は明示的に配分する。
右下の扱いが、そのプロジェクトの成熟度を分ける。年に一度しか起きない処理は、UATの期間中に自然発生しない。だから意図的にシナリオを作って通す必要がある。ここを飛ばすと、本番の期末で初めて操作することになり、しかも締めの真っ最中に初見の画面と向き合う。
右上も軽視されやすい。日次で回る処理は「毎日やっているから大丈夫」と思われがちだが、間違いが毎月積み上がる分だけ後戻りが重い。入金消込のロジックが甘いまま稼働すると、消し込めない入金が滞留し、売掛の残高が回収の意思決定に使えなくなる（SAPの債権・債務管理（AR/AP）を回収と支払の意思決定に効かせる）。
テストデータを、きれいに作らない
UATが「通ってしまう」最大の原因が、テストデータの品質が良すぎることだ。ベンダーが用意する検証用データは、マスタが揃い、金額が丸く、取引が正常系で完結している。そのデータで回せば、当然ほとんど通る。
本番のデータは違う。取引先マスタの支払条件が空欄、住所が旧本社のまま、同じ会社が二重登録、桁が一つ多い伝票、部分入金と過入金、マイナスの請求、締めた後に届く前月分の請求書、他通貨の少額取引。これらを意図して混ぜる。
いちばん確実なのは、過去の実データを移行して回すことだ。前年同月の取引を丸ごと入れて締めてみれば、当時の決算数値と突き合わせられる。差が出たところが、設計と現実のずれである。移行データの品質はここで一緒に検証できるので、データ移行の工程とUATを分断しないほうがよい（SAP移行のデータ移行で失敗しない｜マスタ品質を上げる進め方）。
件数も本番相当に寄せる。数十件で通った月次締めが、数万件では時間内に終わらないことがある。処理時間は非機能要件としてベンダー側で検証されている前提だが、経理が締めのスケジュールを組めるかどうかは、実際の件数で回してみないと判断できない。5営業日で締める計画なら、どの処理が何日目の何時に走るかまでUATで確定させる（決算スケジュール表の作り方：5日締めを支えるWBSとクリティカルパス）。
「期間」を動かさないテストは、締めのテストではない
経理のUATで最も抜けやすいのが、時間軸の操作だ。伝票を入れるテストは誰でも思いつくが、期間を閉じたり開けたりするテストは、テストケース一覧に載らない。
見るべきは次のような点になる。会計期間をクローズした後、そこへ伝票を起票しようとするとどうなるか。誰が期間を再オープンできるのか。再オープンした事実が記録に残るか。月をまたぐ検収の費用がどちらの月に落ちるか。前月の誤りを当月で訂正した場合、部門別P/Lの前月分は動くのか動かないのか。年度の繰越処理を実行した後で前年度の伝票を直したら、繰越残高は自動で追随するのか。
このあたりは設計上の選択が入るところで、正解が一つではない。だからこそ、UATで経理が「この挙動でよい」と確認する意味がある。締めた後の修正をどう統制するかは、内部統制の評価でも問われる論点になる（SAPの会計期間クローズ（期間オープン管理）：締めた後の修正をどう統制するか）。
内部統制といえば、システム導入そのものが評価の対象になる点も押さえておきたい。2023年4月に改訂された「財務報告に係る内部統制の評価及び監査の基準」は、2024年4月1日以後に開始する事業年度から適用されている。基幹システムの入替えは、IT全般統制とIT業務処理統制の両方に影響する事象であり、稼働年度の内部統制評価では監査人から必ず論点になる。UATの記録は、そのときの証跡そのものだ。誰が何をテストして誰が承認したかが残っていない受入れは、後で説明ができない。
合否を「不具合ゼロ」で判定しない
UATの終盤で必ず起きるのが、残った不具合をどう扱うかの綱引きだ。ベンダーは「軽微なので稼働後の対応で」と言い、経理は「直ってから」と言う。この議論は、判定基準を不具合の数に置いている限り終わらない。
置き換えるべき基準は一つで、残った不具合それぞれについて、稼働後どう回すかが決まっているかである。回避手順があり、担当が決まり、いつまでに恒久対応するかの期日が入っている。この三点が揃っていれば、直っていなくても稼働の判断はできる。揃っていないものが一件でもあれば、それは軽微かどうかにかかわらず未決である。
そして、この一覧はUATの成果物として稼働後に引き継がれなければならない。落とした要件と運用での回避策が現場に渡らないと、担当者は自分でExcelを作って埋める。稼働後に二重管理が生まれる典型的な経路がこれだ（SAP稼働後にユーザーが使わなくなる理由｜定着を決めるのは操作研修ではない）。Fit-to-Standardの議論でアドオンを見送った箇所も同じで、見送りの判断とセットの運用回避策が議事録の中に眠ったままになる（SAPアドオン（追加開発）をどこまで作るか｜Fit-to-Standardの判断基準）。
UATは検収でなく、運用のリハーサル
UATを検収の手続きだと捉えると、経理の関わり方は「渡されたケースを消化して署名する」になる。それで署名した合格は、稼働後に何の役にも立たない。
代わりに、稼働後の1か月をここで先に生きるのだと考える。同じ件数、同じ汚れたデータ、同じスケジュール、同じ人員で締めてみる。詰まった箇所が、稼働後に詰まる箇所である。テストの合格率でなく、締めが何日で終わったかを持ち帰る。プロジェクトに経理がどう関わるかという議論はよくあるが、関わり方の中身はここに集約される（SAP移行プロジェクトに経理財務はどう関わるべきか｜丸投げで失敗しない）。
