調達から支払いまでの請求書処理用データテンプレート
調達から支払いまでの請求書処理用データテンプレート
これは調達から支払いまで:請求書処理向けの汎用プロセスマイニング用データテンプレートです。より詳しい手順については、システム別のテンプレートをご利用ください。
特定のシステムを選択- 詳細な分析に推奨されるデータ項目
- 追跡する主要なアクティビティとマイルストーン
- プロセスデータの抽出方法
調達から支払いまでの請求書処理の属性
| 名前 | 説明 | ||
|---|---|---|---|
| アクティビティ名 ActivityName | 請求書処理の過程で発生した、特定の業務イベントまたはタスクの名前です。 | ||
| 説明 アクティビティ名は、請求書処理の流れにおける個々のステップや節目を表します。たとえば、「請求書を受領」「請求書を承認申請」「支払いブロックを設定」「支払いを実行」などがあります。この属性によって、時間の経過とともに請求書に何が起きたかを把握できます。 プロセスマイニングでは、この属性を使ってワークフローを視覚的に表すプロセスマップを作成します。アクティビティの順序、頻度、経路を分析すると、よくあるプロセスフロー、逸脱、ボトルネック、やり直しのループを特定できます。意味のある改善につながるプロセス分析を行うには、アクティビティ名の品質と粒度が重要です。 重要な理由 この属性がプロセスの各ステップを定義し、プロセスマップの基盤となることで、フローに関するあらゆる分析が可能になります。 入手先 通常、ソースシステムのステータス変更ログ、イベントテーブル、または取引コードから取得します。 例 請求書を入力請求書を承認支払いブロックを設定支払いを実行 | |||
| イベント時刻 EventTime | 特定のアクティビティまたはイベントが発生した日時を示す正確なタイムスタンプです。 | ||
| 説明 イベント時刻(開始時刻)は、業務アクティビティが行われた正確な日時を記録します。「請求書を受領」から「支払いを実行」まで、プロセス内の各アクティビティにタイムスタンプが関連付けられます。この時系列データは、イベントの順序付けや所要時間の計算に欠かせません。 この属性を使ってイベントを時系列に並べ、ケースごとのプロセスフローを作成します。アクティビティ間のサイクルタイムの計算、時間が失われているボトルネックの特定、サービスレベル合意に基づくパフォーマンスの監視など、時間に基づく分析の基礎となります。信頼性の高いプロセスマイニング分析には、正確なタイムスタンプが欠かせません。 重要な理由 イベントの時系列を示し、サイクルタイムなど、パフォーマンスや所要時間に関するすべての計算の基礎となります。 入手先 通常、イベントログ、または各取引やステータス変更に関連付けられた「作成日」や「入力日」の項目に記録されています。 例 2023-10-26T10:00:00Z2024-01-15T14:35:10Z2023-11-01T09:12:05Z | |||
| 請求書番号 InvoiceNumber | 仕入先の請求書を識別する一意の番号です。請求書のライフサイクル全体を追跡するための主キーとして使われます。 | ||
| 説明 請求書番号は、仕入先が請求書に付与する一意の英数字コードです。プロセスマイニングでは、通常、ケースIDとして使われ、受領から支払いまでの各請求書の流れを個別に識別します。 請求書番号をケースIDにすると、「請求書を受領」「請求書を承認」「支払いを実行」など、関連するすべてのアクティビティを結び付け、個々の請求書のプロセス全体を再構成できます。これにより、ケースごとのサイクルタイム、経路、逸脱を詳しく分析できます。これはプロセス分析の基盤となります。 重要な理由 関連するすべてのイベントを結び付ける重要なケース識別子です。1件の請求書のライフサイクルを最初から最後まで追跡できます。 入手先 通常、請求書取引テーブルのヘッダーにある主要項目です。 例 INV-2024-001239876543210US-5839A-24 | |||
| ソースシステム SourceSystem | イベントデータの抽出元となるシステムです。 | ||
| 説明 ソースシステム属性は、請求書処理のイベントが記録されたアプリケーションやプラットフォームを示します。複雑なIT環境では、請求書の処理がスキャンソリューション、ワークフローツール、ERPシステムなど、複数のシステムにまたがることがあります。 ソースシステムを把握すると、データの背景を理解し、データ品質の問題を調査しやすくなります。また、複数のシステムにまたがるプロセスを分析し、システム連携の課題やアプリケーション間の引き継ぎによる遅延を明らかにできます。レガシーシステムと最新システムのデータを統合する際にも役立ちます。 重要な理由 データの出所に関するコンテキストを示すため、データの検証や複数のITシステムにまたがるプロセスの分析に役立ちます。 入手先 データ抽出時に追加される固定値の場合や、アプリケーション名またはIDを示すシステムログの項目として記録される場合があります。 例 SAP_ECC_PRODOracle_Fusion_FINCoupa_R34 | |||
| 最終データ更新 LastDataUpdate | このイベントのデータがソースシステムから最後に更新された日時を示すタイムスタンプです。 | ||
| 説明 この属性には、データが最後に抽出または更新された日時が記録されます。分析対象のデータセットがどれだけ新しいかを示すメタデータ項目です。 プロセスマップの作成に直接使うものではありませんが、分析の鮮度を把握するうえで重要です。リアルタイムのデータを見ているのか、特定時点のスナップショットを見ているのかを確認できるため、業務上の判断に役立ちます。また、データパイプラインの状態や更新頻度を監視するうえでも重要です。 重要な理由 データの鮮度を示し、プロセス分析がどの時点の状況を反映しているかを把握できます。 入手先 通常、データの抽出、変換、読み込み(ETL)の過程で生成され、データセットに追加されます。 例 2024-05-21T04:00:00Z2024-05-20T04:00:00Z2024-05-19T04:00:00Z | |||
| ブロックまたは却下の理由 BlockOrRejectionReason | 請求書の支払いがブロックされた場合、または承認時に却下された場合の理由です。 | ||
| 説明 この属性には、承認ワークフローで却下された場合や、承認後に支払いがブロックされた場合に、請求書の処理が止まった具体的な理由が記録されます。「数量の誤り」「価格の不一致」「発注書番号の欠落」「請求書の重複」などが理由として挙げられます。 根本原因の分析に特に役立つ属性の1つです。理由ごとの発生頻度を分析すると、請求書処理の摩擦や非効率の主な原因を特定できます。データに基づいて、仕入先との連絡方法の改善、発注書に関するコンプライアンスの徹底、担当者へのトレーニングなど、根本的な問題への対策を検討できます。 重要な理由 根本原因の分析に役立ち、処理遅延、手戻り、非効率の主な原因を特定できます。 入手先 通常は請求書取引データまたは関連する承認ログの「理由コード」や「保留理由」などの項目に記録されています。 例 価格の不一致数量の誤り請求書の重複入庫記録の欠落 | |||
| ユーザー User | アクティビティを実行したユーザー、従業員、またはシステムエージェントです。 | ||
| 説明 ユーザー属性は、請求書処理のワークフローにおける特定のステップを実行した担当者または自動システムを示します。請求書を入力した買掛金担当者、承認したマネージャー、照合作業を行った自動ボットなどが該当します。 ユーザー別にデータを分析すると、業務量の分布や個人のパフォーマンスを把握し、トレーニングが必要な領域を特定できます。プロセスマップをユーザーで絞り込み、チームや担当者ごとの請求書処理の違いを確認することもできます。こうした分析から、優れた成果を上げている担当者や振り分け上の問題を見つけたり、追加の支援や社内手順に関するトレーニングが必要なユーザーを特定したりできます。 重要な理由 業務量の分布やユーザーのパフォーマンスを分析し、チームや担当者によるプロセスの違いを把握できます。 入手先 通常は取引の詳細情報にあり、「ユーザー名」「入力者」「変更者」「承認者」などの項目名で記録されています。 例 j.doeSYSTEM_RFCAlice.Smithapprover_pool_1 | |||
| 仕入先名 VendorName | 請求書を提出した仕入先の名前です。 | ||
| 説明 この属性には、請求書を発行した外部取引先の名前が記録されます。取引を特定の仕入先との関係に結び付ける情報であり、財務データの分析に役立ちます。正確なレポートや分析には、一貫性のある整備された仕入先データが欠かせません。 プロセスマイニングでは、仕入先名を主要な分析軸として使い、取引量の多い仕入先や問題のある仕入先の請求書処理を絞り込んで確認できます。エラーのある請求書を頻繁に提出する仕入先を特定し、遅延や手戻りの原因を調べるのに役立ちます。また、仕入先のパフォーマンス管理や優先仕入先プログラムの検討にも利用できます。 重要な理由 仕入先別にプロセスを分けてパフォーマンスを分析できます。仕入先管理や、問題のある請求書の発生源を特定するうえで役立ちます。 入手先 通常は請求書ヘッダーのデータにあり、仕入先IDを使って仕入先マスターデータのテーブルと関連付けられています。 例 Global Office SuppliesInnovate Tech SolutionsCity Logistics Inc. | |||
| 支払期日 PaymentDueDate | 支払遅延を避けるために、請求書の支払いを完了する期限です。 | ||
| 説明 支払期日は、請求日と合意済みの支払条件に基づいて算出される重要な日付です。仕入先との良好な関係を保ち、支払遅延による違約金を避けるための期限を示します。 この属性は、期日どおりの支払い状況を監視するうえで基本となります。期日どおりの支払率などの重要業績評価指標(KPI)の算出や、支払遅延のリスクがある請求書の特定に使われます。請求書の承認日から支払期日までの期間を分析すると、最終段階の支払予定の設定や実行が効率的かどうかを評価できます。 重要な理由 期日どおりの支払い状況を測定し、支払いが遅れる原因を分析するために欠かせません。 入手先 通常は請求書取引の詳細情報にあります。直接入力される場合と、請求日および支払条件から算出される場合があります。 例 2024-06-302024-07-152024-08-01 | |||
| 終了時刻 EndTime | アクティビティまたはイベントが完了した時刻を示すタイムスタンプです。瞬時に完了するイベントでは、開始時刻と同じになることがよくあります。 | ||
| 説明 終了時刻属性には、プロセスのステップが完了した正確な時刻が記録されます。アクティビティの所要時間を正確に計算するために欠かせない、プロセスマイニングの基本指標です。開始時刻と終了時刻を比較すると、各ステップにかかる時間を測定し、ボトルネックや効率改善の余地がある箇所を特定できます。 分析では、終了時刻を使って個々のアクティビティやプロセスの各区間のサイクルタイムを計算します。たとえば、「請求書を承認」したアクティビティの終了時刻から開始時刻を差し引くと、「請求書の承認」ステップの所要時間を求められます。このデータは、パフォーマンスを示すダッシュボードの作成、ベンチマークの設定、プロセス変更の影響の監視に役立ちます。 重要な理由 アクティビティの所要時間を正確に計算できるため、ボトルネックの特定や処理効率の測定に役立ちます。 入手先 システムログや取引データに記録されています。「完了日」「変更日」、またはアクティビティの完了を示す個別のタイムスタンプ項目として記録されることがよくあります。 例 2023-10-26T10:05:12Z2024-01-15T15:00:00Z2023-11-01T09:12:05Z | |||
| 請求通貨 InvoiceCurrency | 請求金額に使用される通貨コードです。例:USD、EUR。 | ||
| 説明 この属性は、請求金額の通貨を示します。海外で事業を展開し、複数の国の仕入先と取引する組織にとって欠かせない情報です。通常はISO 4217規格に準拠した通貨コードを使い、財務データを正しく解釈できるようにします。 分析では、地域別または国別にデータを分ける際に請求通貨を使います。金額を正しく集計する財務レポートにも必要で、多くの場合、基準となる報告通貨への換算が求められます。通貨別にプロセスの違いを分析すると、国際送金や外国為替管理に関する複雑さが明らかになることもあります。 重要な理由 請求金額の通貨を把握できるため、グローバルな業務の正確な財務分析やデータの分類に役立ちます。 入手先 通常、請求書取引テーブルのヘッダーにある標準項目です。 例 USDEURGBPJPY | |||
| 請求金額 InvoiceAmount | 請求書の合計金額です。 | ||
| 説明 請求金額は、すべての明細、税金、手数料を含む請求書の合計金額です。各ケースの金額的重要性を示す基本的な財務属性であり、プロセスへの影響を把握するため、ほかの属性と組み合わせて分析することもよくあります。 この属性は、財務分析や優先順位付けに欠かせません。請求金額で絞り込むことで、高額な請求書により厳格な承認経路が適用されているか、処理が遅れやすいかを調べられます。また、請求書の処理総額を追跡するダッシュボードや、請求金額に対する割合で節約額を算出する割引取得関連の重要業績評価指標(KPI)にも必要です。 重要な理由 財務への影響を分析し、高額な請求書の優先順位を付けるほか、請求金額が処理時間や処理経路に影響するかを確認できます。 入手先 通常、請求書取引テーブルのヘッダーにある標準項目です。 例 5250.751200.0025000.0089.99 | |||
| 会社コード CompanyCode | 請求書を処理する組織内の法人または会社を識別するコードです。 | ||
| 説明 会社コードは、大企業グループ内の特定の法人または子会社を示します。多くの財務システムでは、会計やレポート作成のため、取引を会社コードごとに分けて管理します。 この属性を使うと、事業部門間の比較分析ができます。会社コードごとにプロセスマップを分けて分析すれば、パフォーマンスを比較し、ある法人の優れた取り組みや別の法人に共通する問題を見つけられます。複数の法人を持つ組織がプロセスの違いを把握し、全社的なコンプライアンスを確保するための基本的な属性です。 重要な理由 組織内の法人や事業部門ごとにプロセスを比較し、ベンチマークを行えます。 入手先 通常、すべての財務取引テーブルのヘッダーにある、組織を示す基本項目です。 例 1000US01DE015100 | |||
| 支払条件 PaymentTerms | 支払期日や早期支払い割引の適用条件を定める、請求書の支払いに関する合意内容です。 | ||
| 説明 支払条件は、請求書の支払いについて仕入先と合意した条件です。「Net 30」(30日以内に支払い)や「2% 10, Net 30」(10日以内の支払いで2%割引、そうでない場合は30日以内に全額支払い)のような標準形式で示されます。 この属性は、財務戦略やパフォーマンス分析に欠かせません。支払期日の算出や、早期支払い割引を受けられる機会の特定に使われます。支払条件ごとにプロセスを分析すると、特定の条件が処理遅延と関連しているか、組織が有利な割引を十分に得られているかを確認できます。 重要な理由 期日どおりの支払い状況を分析し、早期支払い割引を受けられる機会を特定するうえで重要です。 入手先 通常は仕入先マスターデータから取得し、請求書ヘッダーに記録されます。 例 Net 30Net 602% 10, Net 30受領時払い | |||
| 発注書番号 PurchaseOrderNumber | 請求書に関連付けられた発注書(PO)の識別番号です。 | ||
| 説明 発注書番号によって、請求書と事前承認済みの調達文書が関連付けられます。照合処理では、この関連付けをもとに、数量や価格などの請求書の詳細が発注書の内容と一致するかをシステムが確認します。 この属性は、照合処理の効率を分析するうえで重要です。発注書に基づく請求書の多くが人手を介さずに処理されていれば、調達プロセスが適切に機能していると考えられます。一方、発注書のない請求書を分析すると、規定外の購買や調達方針が守られていない領域が見つかることがあります。発注書の有無は、プロセスの効率を比較する際によく使われる分類軸です。 重要な理由 発注書のある請求書とない請求書を区別できます。処理経路や効率が異なることが多いため、比較分析に役立ちます。 入手先 通常は請求書取引の明細またはヘッダーにあり、購買文書と請求書を関連付けます。 例 4500018921PO-2024-7837300000456 | |||
| 請求日 InvoiceDate | 仕入先が請求書を発行した日付です。 | ||
| 説明 請求日は、仕入先が請求書に記載した日付です。仕入先側から見た支払いのライフサイクルの起点となり、合意済みの支払条件に基づく支払期日の算出に使われることがよくあります。 請求日から「請求書受領」または「請求書入力」のアクティビティまでの期間を分析すると、請求書の提出やシステムへの取り込みの遅れを特定できます。この「請求書受領までの遅れ」は、サイクルタイム全体に含まれる見えにくい要因となることがあります。期間を短縮すれば、期日どおりの支払いにつながり、早期支払い割引を受けられる機会も増やせます。 重要な理由 仕入先が請求書を発行してからシステムに入力されるまでの「請求書受領までの遅れ」を測定できます。 入手先 請求書ヘッダーのデータにある標準的な日付項目で、「文書日付」または「請求日」と記録されていることがよくあります。 例 2024-05-012024-04-152024-06-10 | |||
| 請求書のステータス InvoiceStatus | 請求書処理のワークフローにおける現在の状態です。 | ||
| 説明 請求書のステータスは、データ抽出時点で請求書のライフサイクルのどの段階にあるかを示します。一般的なステータスには、「処理中」「承認済み」「支払済み」「却下」「ブロック中」などがあります。この属性から、請求書の現在の状況を大まかに把握できます。 プロセスマイニングでは請求書の全行程を再構成しますが、現在のステータスは、進行中の業務量を監視する運用ダッシュボードにも役立ちます。承認待ちやブロック中の請求書が何件あるかなど、各段階の件数をマネージャーが把握できます。これにより、請求書処理の流れを先回りして管理し、ボトルネックや遅延を防ぎやすくなります。 重要な理由 現在の業務量を把握し、「承認待ち」や「ブロック中」など、各段階の請求書件数を監視できます。 入手先 通常は請求書ヘッダーテーブルのステータス項目に記録され、請求書のライフサイクルに応じて更新されます。 例 支払済み処理中却下支払承認済み | |||
調達から支払いまで:請求書処理のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
| 支払いを実行 | 支払いが実行され、請求書の債務が消し込まれるプロセスの最終ステップです。このイベントによって、仕入先への資金の支払いが完了したことを確認できます。 | ||
| 重要な理由 請求書に関する調達から支払いまでのプロセスが正常に完了したことを示します。期日どおりの支払い率とプロセス全体の所要時間を測定するための確定イベントです。 入手先 請求書を消し込む支払文書の転記日から取得します。 記録 仕入先の未消込明細を決済する会計文書から、消込日または支払日を使用します。 イベントタイプ explicit | |||
| 照合の不一致を検出 | システムまたはユーザーが、請求書、発注書、入庫記録の不一致を検出したときに発生します。価格や数量の差異などがあると、通常は請求書が保留され、手作業での対応が必要になります。 | ||
| 重要な理由 こうしたイベントを追跡することは、処理遅延ややり直しの根本原因を分析するうえで欠かせません。仕入先の請求精度や社内の調達プロセスに関する問題の特定に役立ちます。 入手先 照合の失敗を示すステータス変更、または差異に関連するシステム保留の自動適用から推定します。 記録 照合ステータスが「失敗」または「不一致」に設定された時刻、あるいは差異に関連する保留が適用された時刻を記録します。 イベントタイプ inferred | |||
| 請求書の照合が完了 | 請求書と発注書、必要に応じて入庫記録との照合が正常に完了したことを示します。自動または手動で行われるこのステップでは、請求された数量と価格が発注・受領した内容と一致するかを確認します。 | ||
| 重要な理由 これは、処理を中断せずに完了させるうえで重要な節目です。初回の照合で一致する請求書が多いほど、前段階の調達プロセスが効率的に進んでいることを示します。 入手先 通常、照合の検証が正常に完了した時点で、ステータス変更または取引履歴のイベントとして記録されます。 記録 照合ステータスが「合格」「照合済み」または「消込済み」になったことを示すイベントまたはステータス更新を特定します。 イベントタイプ explicit | |||
| 請求書を却下 | 承認者が請求書を正式に却下し、ワークフローの進行が止まったときに発生します。通常、請求書は修正または取り消しのために差し戻され、やり直しが発生します。 | ||
| 重要な理由 請求書の却下を分析すると、誤った勘定コード、方針違反、前段階のデータの問題など、やり直しの根本原因を特定できます。却下を減らすことは、効率向上の鍵となります。 入手先 通常、却下理由とともに、請求書の承認履歴またはワークフローログに明示的な操作として記録されます。 記録 承認者がワークフローで「却下」または「否認」の操作を行ったときに記録されるイベントを特定します。 イベントタイプ explicit | |||
| 請求書を受領 | 請求書がシステムで最初に受領または作成されたことを示します。手入力、サプライヤーポータル、OCRなど、入力方法にかかわらず、請求書処理の開始点となるイベントです。 | ||
| 重要な理由 このアクティビティは、請求書処理の開始から完了までのサイクルタイムを測定するうえで重要です。業務量や処理開始時点の遅延を把握するためのベースラインになります。 入手先 通常、請求書レコードの作成日時、または文書ログへの最初の記録から取得します。 記録 ソースシステムにある請求書または仕入先請求書の主要オブジェクトの作成日時を使用します。 イベントタイプ explicit | |||
| 請求書を承認 | ワークフローで必要なすべての関係者が請求書を承認したことを示します。この節目をもって、請求書の会計転記とその後の支払いが可能になります。 | ||
| 重要な理由 検証と承認の段階を終える重要な節目です。承認にかかるサイクルタイムの測定や、承認方針の遵守状況の確認に欠かせません。 入手先 最終承認時に、承認履歴またはワークフローログに明示的に記録されます。 記録 請求書の承認履歴またはワークフロー履歴に記録された最終承認操作の時刻を使用します。 イベントタイプ explicit | |||
| 請求書を総勘定元帳に転記 | 承認済みの請求書を総勘定元帳に記録する正式な会計イベントです。この処理によって債務が計上され、請求書は処理中の状態から支払い可能な状態に移ります。 | ||
| 重要な理由 債務が正式に認識されたことを確認する、重要な会計上の節目です。このステップまでの遅延は、決算やレポーティングの正確性に影響する可能性があります。 入手先 システムの財務モジュールに、明示的な取引イベントとして記録されます。 記録 請求書から作成された会計文書に関連付けられた転記日を使用します。 イベントタイプ explicit | |||
| 不一致を解消 | 以前に検出された照合の不一致を手作業で調査し、解消した時点を示します。これにより、請求書は承認や再照合などの次のステップに進めるようになります。 | ||
| 重要な理由 不一致の解消にかかる時間は、請求書処理のサイクルタイムを左右する大きな要因です。このアクティビティを分析すると、例外処理に必要な作業量と時間を把握できます。 入手先 照合に関する保留を解除する最初のユーザー操作、または失敗した照合を再処理できるようにする操作から推定することがよくあります。 記録 照合に関する保留が解除されたイベント、または以前の照合失敗後に請求書の照合が正常に完了したイベントを特定します。 イベントタイプ inferred | |||
| 支払いブロックを解除 | 以前に設定された支払いブロックが解除され、請求書が再び支払い可能になったことを示します。ブロックの原因となった問題が解消されたことを表します。 | ||
| 重要な理由 支払いブロックの設定から解除までの時間は、プロセスの遅延を表します。この期間を分析すると、問題解決におけるボトルネックを特定できます。 入手先 請求書レコードの支払いブロックのステータスまたはフラグが解除された時点で記録されます。 記録 支払いブロックコードや保留ステータスが削除された、またはブロック解除の状態に変更されたイベントを記録します。 イベントタイプ explicit | |||
| 支払いブロックを設定 | 請求書が承認済みでも支払われないよう、意図的に保留します。システムルールによる自動設定のほか、仕入先との紛争などを理由に手動で設定する場合もあります。 | ||
| 重要な理由 支払いブロックは、支払い遅延や割引の適用漏れの大きな原因です。支払いブロックがいつ、なぜ設定されたかを特定することは、期日どおりの支払いを増やすうえで重要です。 入手先 通常、請求書レコードまたは明細項目のステータスやフラグとして記録されます。 記録 請求書または明細項目に支払いブロックコードや保留ステータスが適用されたイベントを記録します。 イベントタイプ explicit | |||
| 支払いを予定 | 転記済みの請求書が支払い提案または支払いバッチに選択され、含まれた状態です。特定の日付に支払いを実行するための待ち行列に追加されますが、実際の資金移動を示すものではありません。 | ||
| 重要な理由 このアクティビティによって、プロセスの最終段階を把握できます。転記から支払い予定の設定までの遅延は、割引の適用漏れや支払い遅延の原因になることがあります。 入手先 通常、請求書が支払い処理、支払い提案、または支払い仕訳に追加された時点で記録されます。 記録 請求書を含む支払い提案または支払いバッチレコードの作成日を特定します。 イベントタイプ explicit | |||
| 請求書が期限超過 | 請求書が未払いのまま、現在の日付が正味支払期日を過ぎたときに発生する計算上のイベントです。支払期日は、請求書の日付と仕入先の支払条件に基づいて決まります。 | ||
| 重要な理由 このアクティビティによって支払い遅延を直接把握できます。支払い遅延は仕入先との関係を損ない、違約金が発生する原因にもなります。期日どおりの支払い率を監視し、改善するうえで欠かせません。 入手先 システムに明示的に記録されるイベントではありません。支払日(未払いの場合は現在の日付)と請求書の支払期日を比較して算出します。 記録 支払い済みの請求書では イベントタイプ calculated | |||
| 請求書を修正 | 請求書に手作業で更新や修正を加えたことを示します。却下後の修正や、検出されたエラーの訂正などが該当します。このアクティビティは、標準的な自動処理からの逸脱を表します。 | ||
| 重要な理由 やり直しのアクティビティを追跡すると、プロセスの非効率な箇所や見えにくいコストが明らかになります。請求書が修正される理由を把握することで、対象を絞ったプロセス改善やトレーニングにつなげられます。 入手先 通常、初期入力後に請求書の主要項目が変更されたことを記録する変更ログまたは監査証跡から推定します。 記録 請求書データの変更を示す監査ログの時刻を記録します。特に、却下または保留の後に行われた変更が対象です。 イベントタイプ inferred | |||
| 請求書を入力 | 請求書の詳細を入力またはスキャンし、初期データ入力が完了した状態を示します。転記や正式な承認申請はまだ行われていません。請求書は一時的に保留または下書きの状態になっていることがよくあります。 | ||
| 重要な理由 請求書の受領から入力までの時間を分析すると、データ入力段階の滞留を特定できます。データ取得の自動化ソリューションの効率を把握するのにも役立ちます。 入手先 請求書レコードが下書きまたは保留の状態で保存され、ワークフローに送信される前に発生したものと推定することがよくあります。 記録 請求書のステータスが新規から保存済み、保留、または下書きに変わった時刻を記録します。 イベントタイプ inferred | |||
| 請求書を取り消し | 請求書が無効化、取り消し、またはキャンセルされ、以降の処理や支払いが行われない状態です。誤った請求書や重複した請求書の最終状態を表します。 | ||
| 重要な理由 取り消しを追跡すると、データ品質の問題、重複申請、その他の前段階で発生したエラーを把握できます。取り消し率が高い場合、仕入先の請求処理や社内統制に問題がある可能性があります。 入手先 請求書レコードの明示的なステータス変更、または対応する取消文書の作成として記録されます。 記録 請求書のステータスが「取り消し」または「無効」に変更された時刻、あるいは取消文書が転記された時刻を特定します。 イベントタイプ explicit | |||
| 請求書を承認申請 | 初期検証と照合の完了後、請求書を正式に承認ワークフローへ送信したことを示します。設定された業務ルールに基づいて、指定された承認者に請求書が割り当てられます。 | ||
| 重要な理由 このアクティビティは、承認のサブプロセスの開始点です。このイベントから最終承認までの時間を測定すると、承認ワークフローの効率を分析し、ボトルネックを特定できます。 入手先 ワークフローエンジンを備えたシステムでは明示的なイベントとして記録されます。そうでない場合は、ステータスが「承認待ち」に変わったことから推定できます。 記録 ワークフローが開始された時刻、または承認待ちを示すステータスに請求書が更新された時刻を記録します。 イベントタイプ explicit | |||
データ抽出ガイド
データの抽出方法はシステムによって異なります。詳しい手順は、
まずはここから
データの抽出を始めるには、システム別のガイドを選択してください。任意のデータソースに使える基本資料として、この汎用テンプレートを利用することもできます。
請求書処理を最適化し、調達から支払いまでの効率を高める
プロセスに隠れたインサイトを見つけ、コストを削減し、請求書処理のワークフローを短縮します。
クレジットカードは不要です。わずか5分で設定できます。