財務オペレーション向けの照合画面 UI パターン

照合画面が解決すべきこと

照合画面は実務的な一つの質問に答えるためにあります：二つのデータソースが異なるとき、私たちが報告し運用する「真実」は何か？

通常は「ソース」（銀行フィード、決済プロセッサ、POS、サブレジャー、倉庫システムなど）と「帳簿」（多くは総勘定元帳）を比較します。画面は単なる比較表示ではありません。意思決定が行われ記録される場所です。

不一致は退屈な理由で起こりますが、それは良いニュースです。UI がそれらを予測できるからです。発生する差異には、入力遅延、欠落項目、重複、マッピングの問題（誤った勘定、得意先、通貨）、一方のレコードが他方の複数に対応する部分一致などがあります。

優れた照合画面の利用者の仕事は、推測せずに各例外を「不明」から「解決済み」に移すことです。典型的には次の繰り返し可能なアクションに分かれます：

• 同一取引かどうかを、速やかに判断できる十分な文脈で確認する
• 解決方法を選ぶ：マッチ、分割、マージ、償却、保留など
• 適切なシステムに対して正しい理由で訂正を適用する
• 次の担当者が理解できる明確なメモを残す

最大のリスクは誤った照合ではなく、静かな変更です。画面が値を編集できるようにして、何が変わったか、誰が変えたか、どのレコードが影響を受けたかを示さなければ、信頼を失い、監査時に時間を浪費します。

各解決が追跡可能な結果を生むよう画面を設計してください：変更前/後の値、関連ソースレコード、タイムスタンプ、ユーザー、理由コード。承認が必要ならば、UI は「承認待ち」状態を明瞭に示して、作業があいまいな領域に消えないようにします。

後に AppMaster のようなツールで構築する場合、監査トレイルを副次的なメモではなくファーストクラスのデータモデルとして扱ってください。将来の月次クローズが楽になります。

スケールするシンプルなページ構成

照合画面は、データが散らかっていても落ち着いたチェックリストのように感じられると最も機能します。そこに辿り着く最も簡単な方法は、上部のサマリー、左（または中央）のワークキュー、右の詳細という明確な三分割レイアウトです。

サマリーは「接近しているか？」に答えます。各サイドの合計（件数と金額）を示し、両方の差分を表示します。人は一目で、項目が3つズレているのか、$124.18 の差があるのか、あるいはその両方かを確認できるべきです。できれば「前回保存時から差分が改善した」などの小さなトレンドを入れて、レビュー担当者の作業が効果を出しているかを示します。

ワークキューがスケールの居場所です。検索とフィルタを常に表示しておき、ユーザーが基本操作のために余分なパネルを開かなくて済むようにします。ステータスチップ（New、In review、Corrected、Needs approval）を付けたシンプルな行リストで十分なことが多いです。

多くの照合画面で用いられるクリーンな構成例：

• サマリーバー：左に合計、右に合計、中央に差分
• 期間コントロール：「過去7日」をデフォルトにして30/90/カスタムに素早く拡張
• 常時表示の検索フィールドと主要フィルタ（ステータス、金額範囲、ソース）
• 並べ替え可能なワークキューリストと「次の項目」ショートカット
• 並列表示とアクションボタンを備えた詳細パネル

デフォルトは最小で有用な期間にしてください。例えば最初は過去7日から始め、キューを短く素早く保ち、必要に応じてワンクリックで月全体に拡張できるようにします。これによりノイズが減り、新しいレビュアーが自信をつけやすくなります。

AppMaster のようなツールで構築する場合は、Web とモバイルでレイアウトを一貫させてください：同じ三つのゾーンを小さい画面では積み重ねるだけにして、トレーニングと操作の習慣が共通になるようにします。

人が素早く判断できる不一致の見せ方

良い不一致ビューは、数秒で三つの質問に答えます：何が問題か、どれほど重大か、次に何をすべきか。画面が違いを理解するために三つのモーダルを開かせるなら、人はためらい、推測し、後でメモを残すでしょう。

製品全体で小規模で一貫した不一致タイプのセットを使い始めてください。その一貫性は表現の精密さより重要です。レビュアーは慣れで動きます。多くのチームは「欠落項目」「余分な項目」「金額が異なる」「日付がずれている」の四つで90%のケースをカバーできます。行の先頭にタイプを置き、探さなくて済むようにします。

重大度は明確だが落ち着いた表現にしてください。「High」「Medium」「Low」（あるいは「締めを止める」「要レビュー」「参考」）のようなプレーンなラベルを抑えめの色で使います。色はヒントとして用い、メッセージ全体を担わせないでください。本当に期末の締めを止める案件だけに強い赤を使い、他はニュートラルに保ちます。

レビュアーは「なぜ」を知る必要がありますが、内部用語は避けてください。システムが見つけた内容を参照する短い理由文を表示します（例：「参照でマッチ、金額が異なる」や「銀行取引に対する台帳エントリが見つかりません」）。ルールが関与している場合は、役に立つならルール名を表示し、主要フィールド差分を人間向けの言葉で示します。

生の値と正規化された値を一緒に表示しておくことが大切です。正規化（四捨五入、通貨換算、空白トリム、タイムゾーン変換）は一般的で、それを隠すと不信感を生みます。実用的なレイアウトは、各不一致行内に二列の比較を置くことです：

• ソース A（生データ）：取り込み時のまま（銀行、プロセッサ、ファイル）
• ソース B（生データ）：取り込み時のまま（台帳、ERP、サブレジャー）
• 正規化値：マッチに使われた値、小さな「i」ツールチップで変換の説明
• 差分：単一の計算済差分（例：「+$12.30」や「2 日」）

AppMaster のようなツールで構築するなら、不一致タイプと重大度をデータ層で列挙型（enum）としてモデル化し、リスト、フィルタ、詳細パネルの全てで一貫性を保ちます。

高ボリュームレビュー向けワークキューのパターン

ボリュームが高い場合、照合キューはレポートというより受信箱のように振る舞う必要があります。人は各行を一秒で理解し、次に何をするか決め、文脈を失わずに移動し続けられるべきです。

「それが何か」を「それが意味すること」より先に答える列から始めてください。可能なら最初の画面は必須情報に絞り、詳細はサイドパネルに押し込んでください。

• 参照または ID（銀行取引 ID、仕訳 ID）
• 日付と期間
• 金額と通貨
• 相手方または勘定
• ステータス（open、in review、waiting approval、resolved）

並べ替えはレビュアーの思考に合わせます。良いデフォルトは「差分が大きい順」で、最大のリスクを速やかに表に出します。新着、古い保留、最近タッチされたもののクイック切替も用意しておくと引継ぎが容易です。

保存済みビューがキューを役割横断でスケールさせます。アナリストは「open + auto-match failed」、承認者は「waiting approval only」、監査人は「この期間に手動編集で解決されたもの」を望むかもしれません。ビューはわかりやすく平易な名前にして、各自が独自のスプレッドシートを作らないようにします。

一括選択は時間短縮になりますが、ガードレールがなければ危険です。上限（例：最大50項目）を明示し、どのフィールドが変わるかを示し、不可逆な操作の場合は警告します。簡単なプレビュー段階を入れて大量ミスを防ぎます。

進捗指標はチームを揃えます。状態ごとの件数を上部に表示してクリック可能なフィルタにし、所有権（未割当 vs 自分に割当）が見えると重複作業を防げます。

これらの照合画面 UI パターンは、AppMaster のようなビジュアルツールで構築すると簡単です：キューテーブル、役割ベースの保存フィルタ、ステータスチップで財務チームに迅速さと管理性を両立させます。

手戻りを減らすステップバイステップワークフロー

良い照合フローは派手な見た目よりも、人が画面内を行き来して迷子になるのを防ぐことに重点を置きます。目的は単純です：レビュアーを「何が変わった？」から「何をしたか？」へ文脈を失わずに導くこと。

まずステップ1を避けられないものにします：照合期間と正確なデータソースを選ぶ。これらはページ上部に置き、選択後も表示されたままにします（期間、ソース A、ソース B、最終更新時間）。多くの手戻りは、間違ったデータ抽出に対して不一致をレビューしたときに起こります。

ステップ2は30秒スキャンです。合計差分、未照合項目数、主要な不一致カテゴリ（欠落取引、金額差、日付シフト、重複）を示します。各カテゴリはクリックしてワークリストを絞れるようにします。

ステップ3はスピードが重要になります：項目を一つ開いてフィールドを並べて比較します。主要フィールド（金額、日付、参照、相手方、通貨、勘定）を揃え、証拠をその場で見せます：生データ行、台帳エントリ、添付ドキュメント。証拠を余分なタブの背後に隠さないでください。

ステップ4は意思決定ポイントです。UI は明確な結果を持つ少数のアクションを提示すべきです：

• Match：二つのレコードをリンクしてペアをロックする
• Split：一つのレコードを複数行に振り分け、合計を強制する
• Write-off：理由必須で調整仕訳を作成する
• Escalate：役割や人物に割り当て、期日を設定する
• Ignore：非照合として注記付きでマークする

ステップ5は説明責任です。クリーンなマッチ以外には短いメモを必須とし、承認はルールに従ってのみトリガーしてください（例：閾値を超える償却や閉じたサブレジャーへの調整）。レビュアーが提出前に誰が承認するかを見られるようにして、推測を防ぎます。

ステップ6でループを閉じます。提出後、何が変わったかを確認表示します（例：「Ledger #48321 にマッチ」「調整が作成されました」）と同時に監査エントリを直ちに表示します：タイムスタンプ、ユーザー、アクション、変更前/後のフィールド、承認状況。レビュアーは自分のクリックが反映されたかを疑問に思うべきではありません。

ガードレール付きの訂正ツール

訂正はミスや不正リスクが表れる箇所なので、UI は最も安全な操作を最も簡単にできるようにするべきです。良いルール：まず残高を変えない「安全な」アクションで作業を前に進めさせ、残高を変える操作にはより強い意図を求めます。

まず残高を変えない「安全な」アクションから始めます。これらは往復を減らし、意思決定を可視化します：

• レコードのリンク（銀行行と台帳エントリを編集せずに関連付け）
• 見たことを説明する注釈を追加する
• 所有者に情報を要求する（請求書の欠落、誤った参照、不明な相手方）
• 不審なものはレビューのためにフラグを立てる
• 後で処理するために理由付きでアイテムを保留する

調整を作成する必要がある場合は、フリーテキストではなくガイド付きフォームを使ってください。そのフォームは基本を忘れにくくし、後からレビューしやすくします。照合画面 UI パターンでは、月末に大きな問題を生む「簡単な修正」を防ぐ場所でもあります。

破壊的なアクションは権限と明確な確認の背後に置きます。例えば「調整の削除」は稀でロールベースにし、理由を必須とします。履歴を編集するより新しいレコードを作るアクションを優先してください。

保存前に検証を行い、メッセージで修正方法を示します。シンプルなチェックリストが有効です：

• 必須フィールド：理由コード、金額、適用日
• バランスチェック：調整が差分を許容範囲内に収める
• 必要時の添付：スクリーンショット、ベンダーのメモ、銀行メッセージ
• ポリシーチェック：この勘定と期間で許可された調整か
• 重複チェック：同一参照に対する類似調整が既に存在しないか

元に戻す挙動を明示してください。ユーザーはアイテムを再度開けるか、調整を取り消せるか、相殺仕訳を作成できるかを知るべきです。例：レビュアーが誤って銀行行をリンクし、別の支払いに属することに気づいた場合、編集するより「Unlink（リンク解除）」でノート付きにする方が安全で、何がどうして起きたかの記録が保たれます。

監査トレイルと承認を遅くせずに実装する

監査トレイルは「誰がこのアイテムに手を付けたか、何が変わったか、なぜか」を速く答えられるものでないと役に立ちません。コツは必要なときに見えるようにし、通常のレビューの流れを阻害しないことです。

アクションを保管するだけでなく読みやすくする

アイテム詳細パネルにはコンパクトなタイムラインを追加します。各エントリはアクター、タイムスタンプ、アクション、変更の短い要約を示します。読みやすく一貫性を持たせ、レビュアーが最後の重要なイベント（例：「金額修正」「承認済み」）を一目で見つけられるようにします。

フィールドが修正されたときは、変更前と変更後の両方の値を保存して表示します。タイムライン内にインラインで表示（例：「銀行金額: 1,250.00 -> 1,205.00」）し、「変更内容」を開けばフィールド履歴も見られるようにします。これにより最終値しか保持しないというよくある間違いを避けられます。

ワークフローに馴染む承認

高リスクのアクション（償却、手動オーバーライド、強制マッチ）には理由を求めます。短いドロップダウンと任意のメモを使い、レビュアーが速く進められる一方で説明も残せるようにします。

メーカー・チェッカーはメッセージベースではなく状態ベースで動くと最も良いです。Draft、Submitted、Needs info、Approved、Rejected、Escalated のようなシンプルな状態を使い、アイテムタイトル近くに現在の状態を表示します。承認 UI は簡潔に保ちます：

• 役割に応じた主要アクション（Submit または Approve）
• 二次アクション（Request info または Reject）
• ポリシーが要求する場合の理由必須
• エスカレーション用の担当者/キュー
• 「次に何が起きるか」の明確ラベル（例：「承認で訂正を投稿します」）

最後に、証拠を照合アイテム自体に添付しておきます：ファイルアップロード、メールやチャットの参照、外部 ID、ノート。レビュアーが決定を正当化するためにシステム間を探し回る必要がないようにします。AppMaster のようなツールでは、これを "Reconciliation Item" レコードと関連する "Evidence" や "Approval Events" にマッピングでき、UI はシンプルに保ちつつデータは完全に残せます。

ナイーブな設計を破るエッジケース

多くの照合画面は実データが現れるまで問題を起こしません。破綻点は予測可能なので、早い段階でそれらを想定して設計するのが有利です。

部分一致は最初の罠です。1対1のマッチ表は、銀行振込が三つの請求書を支払ったときや、五回のカード決済が一つの台帳エントリにまとめられると崩れます。これらを一級市民として扱い、レビュアーが合計と「未配分額」指標、明確なグループラベル（例：「3 items -> 1 posting」）を確認できるようにします。グループは展開可能にして、詳細を確認しつつサマリを失わないようにします。

重複は二番目の罠です。人はしばしば間違った項目をマッチと見なして重複を「修正」します。金額、日付のウィンドウ、相手方に基づく「可能性のある重複」のソフトヒントを追加してください。ただし安全に：レビュアーが比較ビューを開いて正しいレコードを選び、他方を理由付きで重複としてマークできるようにします。マージを提供する場合は可逆にし、常に元の ID を保持します。

通貨や端数の差は一般的で、エラーのように見せないでください。正確な計算（レート、手数料、丸め）を示し、通貨や勘定、取引タイプごとに閾値を設定できるようにします。UI は「許容範囲内」か「要対応」かを示すべきで、単に「マッチ/アンマッチ」と表示しないでください。

期が閉じた後に解決する項目は混乱を招きます。項目が期閉後に解決した場合は履歴を書き換えないで、「期閉後に解決」として解決日を表示し、閉じた期間の数値を変更する場合はメモや承認を必須にします。

最後に、障害やフィード欠落は起こります。再確認を容易にするステータスを追加します：

• 「Feed delayed」：次回実行予定
• 「Missing source record」：連絡先情報付き
• 「Manually verified」：レビュアーとタイムスタンプ付き
• 「Needs re-import」：再試行アクション付き

AppMaster で構築するなら、これらの状態を Data Designer でモデル化し、Business Process Editor で許可遷移を強制してエッジケース処理を一貫して監査可能にします。

例：月次の銀行対台帳照合シナリオ

月末です。銀行明細は4月に $248,930.12 の活動を示していますが、内部台帳は $249,105.12 を計上しています。照合画面は、三つの質問に速く答えるサマリーで開きます：何件がマッチしているか、何件が不一致か、未解決の金額はどれくらいか。

サマリーパネルにはこう表示されます：1,284 件がマッチ、3 件が不一致、未解決差分は $175.00。小さな呼び出しで「2 件が対応必要」と表示されます（1 件は情報表示のみ）。

不一致テーブルはタイプ別にグループ化され、次のステップが明確です：

• 銀行手数料が記録されていない：$25.00（対応必要）
• 台帳に重複ペイアウト：$150.00（対応必要）
• タイミングの遅れ：$0.00 差分（情報、決済待ち）

行をクリックすると、右側に Item Details が開きます。$25.00 の手数料については、Item Details に銀行行（日時、説明、金額）と台帳側（一致するエントリなし）が並び、短い提案修正が表示されます：「経費仕訳を作成：Bank fees」。ユーザーは訂正理由を選び、メモを追加し、銀行明細行を証拠として添付します。

$150.00 の重複ペイアウトでは、Item Details に一つの銀行支払いに対して二つの台帳エントリがマッチしていることが表示されます。ユーザーは一つを重複としてマークし、「仕訳を取り消す」を選び、画面は逆仕訳の案を作成します。これは帳簿を変更するため承認フローに回され、ステータスは「Pending approval」となり、その不一致はもはや「未レビュー」にはカウントされません。

タイミング差は別の見え方をします。銀行は4月30日に支払いが開始され、決済は5月1日でした。ユーザーは解決状態を「Timing difference」に設定し、予想決済日を選択して、次期間に「Open carryover」として移します。

後で監査人は推測することなく次を確認できます：

• 各不一致を誰がレビューし、誰が承認し、いつ行ったか
• 編集や逆仕訳の変更前と変更後の値
• 解決状態に紐づく理由コード、メモ、証拠
• 4月が承認された訂正のみで閉じられ、持ち越しは明確にマークされていること

照合期間を閉じる前の簡単チェック

期間を閉じるときは、小さな UI ギャップが後で大問題になります。良いクローズチェックリストは画面上で見やすく、検証しやすく、誤ってスキップしにくいものにします。

まず合計です。期間ごとの各ソースの件数と金額を表示し、どの数字が不一致を引き起こしているかを明確に示します（例：「それぞれ 3 件、$1,240.00」）。合計が一致していても件数が合わない場合はそれを明確に示し、レビュアーが済んだと誤認しないようにします。

クローズ前に、すべての例外は最終ステータスと誰でも数週間後に理解できる理由を持っているべきです。「Resolved」だけでは不十分で、「重複課金を取り消した」や「タイミング差、次期間に消える予定」などのメモが必要です。これは同じ照合画面 UI パターンで、繰り返し作業を防ぎます。

短い事前クローズチェックリストを使い、以下が満たされない場合は閉じられないようにします：

• 期間の合計が一致している（ソース間の件数と金額）
• すべての例外に最終ステータス（resolved、accepted、deferred）と理由がある
• 期間内のアイテムに保留中の承認がない
• スポットチェック完了：解決済み項目5件が証拠と明確なメモを持つ
• 期間状態を再現できるスナップショット/エクスポートが利用可能

スポットチェックはシンプルだが強力です。ランダムに5件の解決済みアイテムを開き、三つを確認します：証拠（明細行、領収書、システムログ）、訂正アクション（何が変わったか）、メモ（なぜ有効か）。これらが欠けているなら、UI は人に間違った習慣を教えています。

最後に期間を再現可能にします。キー合計、例外ステータス、メモ、承認を固定する「スナップショット」を提供してください。AppMaster では、これは Business Process によって生成される専用の "Period Close" レコードにできます。後の監査ビューがクローズ時にレビュアーが見たものと一致するようにします。

次のステップ：これらのパターンを動く画面にする

レイアウトより先にデータから始めてください。システムがレコードが何で他とどう関連するかを明確に説明できないと照合画面は混乱します。小さなモデルを定義し、後で拡張できるようにします：ソースファイル/フィード、個別トランザクション、ソース間をつなぐマッチグループ、そして差分を修正するために作成する調整。レビューに必要なフィールド（金額、通貨、日付、参照テキスト）と、地味だが重要なもの（ステータス、所有者、タイムスタンプ）を追加します。

次にロールを早めに確定します。ほとんどのチームは少なくとも三つ必要です：マッチや訂正を提案できるアナリスト、調整にサインできる承認者、閲覧のみで変更できない監査人。権限を後回しにすると、最初のコントロールレビュー時に核となるアクション（編集、元に戻す、再オープン）を作り直すことになります。

それから実務を動かす三つの画面をプロトタイプしてください：

• 注意が必要なものとその理由を示すキュー（未照合、不均衡、承認待ち）
• レビュアーが速く判断できる詳細パネル（並列表示、差分、推奨マッチ）
• 物語のように読める監査タイムライン（誰が何をいつどの値で行ったか）

ステータス遷移は習慣ではなくルールとして定義してください。例えば、グループは残差がゼロ（または設定された許容範囲内）で、必須フィールドがすべて揃い、承認が完了していなければ「Reconciled」に移らないようにします。例外は許容してもよいですが、その場合は理由コードとコメントを強制して監査トレイルを保ちます。

迅速に構築するには AppMaster のようなノーコードプラットフォームを使うと良いです：PostgreSQL バックの Data Designer でデータベースをモデリングし、ウェブ UI ビルダーでキューとパネルを組み立て、視覚的な Business Process エディタでワークフロールールを実装します。最初のバージョンは狭く（1つのソースペア、いくつかのステータス）保ち、実際の月次ケースでテストして、チームが実際に見る不一致に基づいて反復してください。