> 継続的なプロセス改善 > 決算・レポーティング：仕訳処理 > Workiva > データテンプレート

決算・レポーティング：仕訳用データテンプレート

Workiva

決算・レポーティング：仕訳処理の属性 (18) 決算・レポーティング：仕訳処理のアクティビティ (14) 抽出ガイド (1)

決算・レポーティング：仕訳用データテンプレート

このテンプレートでは、決算・レポーティング：仕訳プロセスを分析するために必要なデータの収集方法を詳しく説明します。必須のデータ項目、追跡すべき重要なプロセスステップ、Workivaからデータを抽出するための手順をまとめています。このテンプレートを使うことで、効果的なプロセスマイニングに必要なデータを漏れなく準備できます。

収集を推奨する属性
追跡すべき主要なアクティビティ
データ抽出の手順

イベントログを初めて扱いますか。学ぶプロセスマイニングのイベントログを作成する方法.

テンプレートをダウンロード

決算・レポーティング：仕訳処理の属性

仕訳処理を詳細に分析するため、イベントログに含めることを推奨するデータ項目です。

5 必須 5 推奨 8 任意

	名前	説明
	アクティビティ ActivityName	仕訳に対して実行された特定のプロセスステップまたはイベントの名称です。
説明この属性は、仕訳のライフサイクルにおける特定の時点で実行されたアクティビティを表します。「仕訳作成済み」「レビューに提出された仕訳」「仕訳承認済み」「総勘定元帳への仕訳転記済み」などの主要なマイルストーンを記録します。これらのアクティビティの順序と頻度を分析することが、プロセスマイニングの中心です。プロセスの流れを可視化し、一般的な経路とまれな経路（バリアント）を特定するとともに、仕訳が最も長く滞留するボトルネックを見つけられます。また、承認サイクル時間など、主要なKPIの開始点と終了点を定義するためにも使われます。重要な理由プロセスの各ステップを定義し、仕訳ワークフローの可視化と分析、ボトルネックの特定を可能にします。入手先通常は、Workiva内のイベントログまたはステータス変更レコードから取得します。正確なフィールドは、システムのステータスコードまたはイベント説明からマッピングする必要があります。例仕訳を作成仕訳を確認に提出仕訳を承認仕訳をGLへ転記
	仕訳ID JournalEntryId	単一の仕訳を一意に識別する識別子であり、プロセス分析における主要なケース識別子です。
説明仕訳IDは、作成から最終転記、照合まで、特定の一連の財務取引に関連するすべてのアクティビティとイベントを一意に追跡します。このIDにより、作成、提出、レビュー、承認、転記などの各ステップが、1つの一貫したプロセスインスタンスとして結び付けられます。プロセスマイニングでは、この属性が各仕訳のエンドツーエンドの流れを再構築する基盤になります。仕訳単位でプロセスバリアント、処理時間、手戻りループを分析できるため、個々の仕訳がシステム内をどのように進むかを明確に把握できます。重要な理由仕訳のライフサイクル全体を追跡するための基本キーであり、プロセスの流れ、所要時間、ばらつきを分析できます。入手先 Workivaにおける仕訳レコードの主キーです。具体的なテーブルまたはAPIエンドポイントについては、Workivaのドキュメントをご確認ください。例 JE-2023-08-1001JE-2023-08-1002JE-2023-09-1003
	開始時刻 EventTime	特定のアクティビティまたはイベントが発生した時刻を示すタイムスタンプです。
説明イベント時刻は、アクティビティが発生した瞬間を記録する、日付と時刻を含む正確なタイムスタンプです。このデータは、イベントを正しい順序に並べ、時間に基づく分析を行うために欠かせません。プロセスマイニングでは、この属性を使ってアクティビティ間の所要時間、ケース全体のサイクル時間、待機時間を計算します。「仕訳承認サイクル時間」や「資料添付遅延時間」など、サイクル時間を分析するダッシュボードの基盤となり、プロセスの遅延や非効率を特定するためにも使われます。重要な理由すべての所要時間の計算、イベントの正しい順序付け、時間経過に伴うプロセスパフォーマンスの分析に欠かせないタイムスタンプです。入手先通常は、Workivaの取引テーブルまたはログテーブルで、各イベントまたはステータス変更とともに保存されます。例 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:05:00Z
	ソースシステム SourceSystem	仕訳データを抽出した記録元のシステムです。
説明この属性は、プロセスデータの発生元であるアプリケーションを識別します。この分析では、値は一貫して「Workiva」になります。単一システムの分析では固定値に見えますが、データガバナンスと追跡可能性に欠かせないメタデータです。大規模な企業環境では、プロセスが複数のシステムにまたがることが多いため、このフィールドが完全なデータリネージュの把握と、複数のソースからのデータの正確な統合に役立ちます。重要な理由プロセスデータの発生元を明確にし、データリネージュと背景情報を提供します。特に複数システムの環境で役立ちます。入手先通常は、データの発生元を示すため、データの抽出・変換処理中に追加される固定値です。例 Workiva
	最終データ更新 LastDataUpdate	ソースシステムからデータが最後に更新された時刻を示すタイムスタンプです。
説明この属性は、Workivaから直近にデータを抽出した日時を記録します。分析対象データがどの時点のものかを把握するための情報です。プロセス分析ダッシュボードでは、分析結果がどの程度新しいものかを理解するために欠かせません。リアルタイムデータを見ているのか、特定時点のスナップショットを見ているのかを判断できるため、業務上の意思決定に役立ちます。重要な理由データの更新状況を示し、分析が最新のプロセス状態を反映しているかどうかを把握できるようにします。入手先通常は、データの抽出・変換・ロード（ETL）処理中に生成され、保存されます。例 2023-10-27T02:00:00Z
	ユーザー User	アクティビティを実行した担当者のユーザーIDまたは氏名です。
説明この属性は、仕訳の作成者、レビュー担当者、承認者など、特定のアクティビティを担当した個人を識別します。一意のユーザーID、氏名、またはメールアドレスを指定できます。ユーザー別にデータを分析することは、業務量の分布、パフォーマンス、コンプライアンスを把握するために欠かせません。「仕訳業務量分布」や「仕訳却下分析」などのダッシュボードで、ユーザー別にアクティビティを分解し、トレーニングの必要性やリソースの偏りを明らかにできます。重要な理由業務量の分布や高い成果を上げている担当者を分析し、ユーザーごとの行動やボトルネックを把握するための重要な属性です。入手先通常は、Workivaのイベントログまたは取引ログで、記録された各アクティビティに関連付けて確認できます。例 asmithbjonescchen
	仕訳ステータス JournalEntryStatus	仕訳のライフサイクルにおける現在のステータスです。
説明この属性は、「ドラフト」「承認に提出済み」「承認済み」「転記済み」「却下」など、仕訳の現在の状態を示します。データ抽出時点で仕訳がどの段階にあるかを表すスナップショットです。業務のモニタリングに欠かせず、「現在の仕訳ステータス概要」ダッシュボードの基盤になります。各プロセス段階の現在の業務量と滞留を明確に把握できるため、リソースの配分や優先順位付けに役立ちます。重要な理由仕訳がプロセスのどの段階にあるかをリアルタイムに把握でき、業務のモニタリングと滞留管理に役立ちます。入手先 Workivaの仕訳ヘッダーにある標準フィールドで、現在の状態を示します。例下書き承認待ち転記済み却下
	仕訳タイプ JournalEntryType	通常仕訳、見越仕訳、修正仕訳など、仕訳の分類です。
説明この属性は、業務上の目的に基づいて仕訳を分類します。一般的なタイプには、定常的な取引に使う通常仕訳、収益や費用を認識する見越仕訳、振替仕訳、修正仕訳があります。比較分析に欠かせない項目です。仕訳タイプごとにプロセスを分けることで、特定のタイプの処理に時間がかかるか、却下率が高いか、異なる経路をたどるかを確認できます。たとえば「仕訳反転率の推移」ダッシュボードでは、タイプ別に反転を分析し、特定の会計処理に起因する問題を切り分けられます。重要な理由プロセスを仕訳タイプ別に分け、特定のタイプで遅延、手戻り、逸脱が多く発生していないかを確認できます。入手先通常は、Workivaの仕訳ヘッダーにある標準フィールドです。例標準未払計上振替修正
	仕訳金額 JournalEntryAmount	仕訳の合計金額で、通常は借方または貸方の合計額です。
説明この属性は、仕訳に関連する主要な財務金額を表します。借方合計額を指定する場合があり、その金額は貸方合計額と一致する必要があります。財務金額別にプロセスを分析すると、重要な傾向を把握できます。たとえば、高額な仕訳はより厳しい確認の対象となり、より厳格な承認経路をたどる場合があります。この属性でダッシュボードを絞り込み、仕訳金額と処理時間、手戻り率、承認遅延の関係を分析できます。重要な理由財務的な影響に基づく分析を可能にし、高額な仕訳が異なる方法で処理されるか、遅延しやすいかを確認できます。入手先 Workivaの仕訳ヘッダーデータにある基本的なフィールドです。例 15000.00250.50125000.75
	部門 Department	仕訳を起票した事業部門またはコストセンターです。
説明この属性は、仕訳に関連する組織単位を識別します。財務、営業、マーケティングなどが該当し、通常はコストセンターまたは仕訳作成者によって決まります。部門別にプロセスを分析すると、組織内の各部門のパフォーマンスを比較できます。プロセスが最も効率的な部門、手戻り率が高い部門、承認時間が長い部門を特定し、ベストプラクティスの共有や重点的な支援につなげられます。重要な理由異なる事業部門のパフォーマンスを比較し、部門固有の問題やベストプラクティスを特定できます。入手先通常は仕訳ヘッダーデータで確認でき、作成者のユーザープロファイルから参照するか、コストセンターとして指定されます。例財務北米営業EU業務運用
	会社コード CompanyCode	仕訳を記録する特定の法人を識別するコードです。
説明会社コードは、企業グループ内の独立した法人を表します。法定報告と連結のため、財務取引はこの単位で記録されます。複数法人を持つ組織では、会社コード別に仕訳プロセスを分析することが欠かせません。特定の法人や地域に固有のプロセスパフォーマンス、コンプライアンス、効率の違いを明らかにし、より的を絞ったプロセス改善につなげられます。重要な理由組織内の異なる法人間でプロセスパフォーマンスを分析・比較するために欠かせません。入手先 Workivaを含む企業会計システムの仕訳ヘッダーデータにある基本的かつ必須のフィールドです。例 1000US01DE01
	却下理由 RejectionReason	レビューまたは承認プロセスで仕訳が却下された理由を説明するコードまたはテキストです。
説明仕訳が却下された際に、レビュー担当者または承認者が示した理由を記録します。理由には、「誤った総勘定元帳勘定」「資料不足」「計算エラー」「ポリシー違反」などがあります。この情報は、手戻りの根本原因分析に役立ちます。却下理由の傾向を分析することで、ユーザー向けの重点的なトレーニング、より明確な手順、システム統制の改善など、改善すべき領域を特定できます。「仕訳手戻り分析」や「仕訳却下分析」ダッシュボードに欠かせない属性です。重要な理由手戻りの根本原因を直接把握でき、トレーニング、資料、プロセス統制を重点的に改善できます。入手先通常は専用フィールド、またはWorkivaの「仕訳却下」アクティビティに関連付けられたコメント／メモフィールドに保存されます。例証憑不足使用した総勘定元帳勘定の誤り金額がしきい値を超過
	手戻りあり IsRework	仕訳がライフサイクルのいずれかの時点で却下または修正されたかどうかを示すフラグです。
説明ケースごとに計算するブール属性です。仕訳のアクティビティ順序に「仕訳却下」や「仕訳修正」などのイベントが含まれる場合、「true」に設定されます。この属性により、手戻りを示す明確な二値フラグを作成でき、フィルタリングや集計が容易になります。「仕訳手戻り率」KPIの計算や「仕訳手戻り分析」ダッシュボードの基盤となり、標準経路から外れて追加作業が必要なケースをすばやく特定できます。重要な理由修正が必要だったすべての仕訳を識別・分析するためのシンプルなフラグであり、プロセス品質と初回正解率の測定に役立ちます。入手先ケースごとにイベントログ内の手戻り関連アクティビティ（「仕訳却下」など）の有無を確認して算出する派生属性です。例 truefalse
	承認サイクル時間 ApprovalCycleTime	仕訳をレビューに提出してから最終的に承認されるまでの経過時間です。
説明承認フェーズ全体の所要時間を測定する計算指標です。通常は、各仕訳について、最初の「レビューに提出された仕訳」イベントから最後の「仕訳承認済み」イベントまでの時間差として計算します。レビューと承認のワークフローの効率を直接測定する指標であり、多くの財務部門にとって主要なKPIです。「仕訳承認サイクル時間」ダッシュボードの基盤となり、ボトルネックの特定や、承認の迅速化を目指すプロセス改善施策の効果測定に役立ちます。重要な理由承認プロセスの効率を直接測定し、遅延箇所の特定に役立つ重要なKPIです。入手先イベントログに記録された「レビューに提出された仕訳」と「仕訳承認済み」アクティビティのタイムスタンプから算出する計算指標です。例 25920086400604800
	終了時刻 EndTime	特定のアクティビティまたはイベントが完了した時刻を示すタイムスタンプです。
説明終了時刻は、アクティビティが完了した正確な時点を記録します。多くのプロセスイベントは瞬時に発生するため開始時刻だけを持ちますが、ユーザーがタスクを開いてから提出するまでのレビューなど、所要時間を測定できるアクティビティもあります。この属性は主に、アクティビティの処理時間（実作業時間）を計算し、アイドル時間や待機時間と区別するために使われます。「仕訳レビュー済み」などのタスクにユーザーが実際にどれだけ時間を費やしたかを把握する分析に役立ちます。重要な理由アクティビティの実際の処理時間を計算し、正確な効率分析のために実作業時間と待機時間を分けられます。入手先 Workivaのドキュメントをご確認ください。単一のアクティビティについて、開始イベントと完了イベントの両方を取得して算出する必要があります。例 2023-10-26T10:15:00Z2023-10-26T11:45:00Z2023-10-27T14:10:00Z
	自動処理かどうか IsAutomated	アクティビティがシステムによって実行されたか、人が実行したかを示すフラグです。
説明このブール属性は、「自動検証実行」のようにシステムが自動的に実行したアクティビティと、「仕訳レビュー済み」のようにユーザーが手動で実行したアクティビティを区別します。この区別は、プロセス効率と自動化の可能性を正確に測定するために欠かせません。人に起因するボトルネックとシステムに起因するボトルネックを分け、プロセスに必要な実際の手作業量を計算できます。自動化の拡大と手作業の接点削減を目指す取り組みに役立つ属性です。重要な理由システムによるアクティビティと人によるアクティビティを区別し、自動化レベルの分析や手作業のボトルネックの特定に役立ちます。入手先多くの場合、派生属性です。アクティビティの「ユーザー」がシステムアカウントまたはサービスアカウントかどうか、あるいはアクティビティ名自体が自動処理を示しているかどうかで判定できます。例 truefalse
	資料あり HasSupportingDocumentation	レビューへの提出前に補足資料が添付されていたかどうかを示すフラグです。
説明この属性は、対象の仕訳について、「補足資料添付済み」アクティビティが「レビューに提出された仕訳」アクティビティより前に存在するかを確認するブールフラグです。「仕訳資料コンプライアンス」ダッシュボードと「仕訳資料添付率」KPIを直接支えます。適切な資料がない仕訳は、却下、遅延、監査指摘につながる可能性があるため、コンプライアンスと監査可能性に欠かせません。分析結果を使ってポリシーを徹底し、レビュープロセスを効率化できます。重要な理由資料に関するポリシーへのコンプライアンスを直接測定し、情報不足による手戻りや遅延の削減に役立ちます。入手先ケースごとのプロセスデータでアクティビティの順序を確認して算出する派生属性です。例 truefalse
	転記日 PostingDate	仕訳が総勘定元帳に正式に記録された日付です。
説明転記日は、財務報告上の取引の有効日です。仕訳が財務諸表に反映される会計期間を決定します。仕訳の作成日や承認日とは異なる場合があります。この属性は、財務分析とコンプライアンス分析に重要です。会計期間の締めに対する仕訳転記の適時性を分析できます。承認から転記までの遅延は、財務締めに影響するシステムまたはプロセスのボトルネックを示す場合があります。重要な理由財務報告における重要な日付であり、転記の適時性と財務締めサイクルへの影響を分析できます。入手先 Workivaの仕訳ヘッダーデータにある標準的な日付フィールドです。例 2023-10-312023-11-302023-12-31

必須推奨任意

決算・レポーティング：仕訳処理のアクティビティ

仕訳処理のワークフローを正確に発見・分析するため、イベントログに記録する主要なプロセス手順とマイルストーンです。

6 推奨 8 任意

	アクティビティ	説明
	仕訳の取消を処理	過去に転記された仕訳を取り消し、元の仕訳を相殺する新しい仕訳を作成します。システムに明示的に記録される特定の取引タイプです。
重要な理由このアクティビティは、転記済み仕訳の誤りを示す強い指標です。取消率が高い場合、初回の確認・承認プロセスに問題がある可能性があり、財務情報の正確性に影響するとともに、追加作業が必要になります。入手先特定の取引タイプまたはフラグが取消を示す取引データから取得します。取消仕訳には通常、元の仕訳IDへの参照が含まれます。取得新しい仕訳レコードが「Reversal」タイプで作成され、元の仕訳のIDへのリンクが設定されます。イベントタイプ explicit
	仕訳をGLへ転記	このアクティビティは、承認済みの仕訳が総勘定元帳に正式に転記されたことを示します。主要なプロセスフローが正常に完了したことを表し、通常は最終ステータスの変更または転記取引ログとして記録されます。
重要な理由多くの仕訳における主要な「終了」イベントとして、エンドツーエンドのサイクルタイムと処理量を算出するうえで重要です。この時点で仕訳が財務諸表に影響します。入手先 GL転記を記録する取引ログ、または仕訳のステータスが「Posted」に変更された記録から取得できます。この時点で転記日フィールドが入力されるのが一般的です。取得タイムスタンプと仕訳IDへの参照を含むGL転記テーブル、またはステータスが「Posted」に変更された記録から取得します。イベントタイプ explicit
	仕訳を作成	このアクティビティは、Workivaで新しい仕訳が開始されたことを示します。ユーザーが新しい仕訳レコードを作成した時点で記録され、プロセスのケース識別子となる一意の仕訳IDが生成されます。
重要な理由プロセスの開始点となるこのイベントは、すべての仕訳のエンドツーエンドのサイクルタイムを測定するうえで欠かせません。このアクティビティを分析することで、作業量の発生状況とリソース計画を把握できます。入手先通常、このイベントは、新しい仕訳オブジェクトの作成を記録するWorkivaの監査ログまたは取引テーブルから取得します。作成日時とユーザーIDも記録されます。取得新しい仕訳レコードの作成時に監査証跡またはテーブルへ記録され、「Created On」タイムスタンプと関連付けられます。イベントタイプ explicit
	仕訳を却下	確認担当者または承認者が、誤り、情報不足、ポリシー違反を理由に仕訳を却下します。この操作により仕訳は作成者へ戻され、修正が必要になります。通常、ステータスが「Rejected」または「Needs Rework」に変更されたことで記録されます。
重要な理由このアクティビティは、プロセスの非効率を生む主な要因である手戻りループの起点になります。却下を分析することで、教育の必要性、共通するエラー、分かりにくいプロセスガイドラインを特定できます。入手先仕訳の履歴ログにおけるステータス変更から推定します。ステータスが「Rejected」に更新され、操作を行ったユーザーとタイムスタンプとともに記録されます。取得ステータスフィールドが「Rejected」または「Sent Back」に更新された時点のタイムスタンプです。イベントタイプ inferred
	仕訳を承認	このアクティビティは、権限を持つユーザーが仕訳を最終承認し、転記可能な状態にしたことを示します。重要な節目であり、通常はWorkivaでステータスが「Approved」に変更されたこととして明示的に記録されます。
重要な理由確認・承認プロセス全体が正常に完了したことを示します。承認サイクルタイムと初回承認率を測定する重要なイベントであり、プロセス効率に直接影響します。入手先仕訳のステータス履歴ログから取得します。レコードのステータスフィールドが「Approved」に更新され、その変更がタイムスタンプと承認者のユーザーIDとともに記録されます。取得仕訳のステータスフィールドが「Approved」に更新された時点のタイムスタンプです。イベントタイプ inferred
	仕訳を確認に提出	ユーザーが作成した仕訳とその書類を、正式な確認・承認ワークフローに提出した時点を示します。通常、Workivaプラットフォーム内の明示的なステータス変更として記録され、「Draft」または「New」から「In Review」へ移行します。
重要な理由このアクティビティは、承認サイクルを開始する重要な節目です。この時点から最終承認までの時間を測定することで、確認プロセスのボトルネックを特定し、承認サイクルタイムを正確に算出できます。入手先仕訳レコードのステータス変更から推定します。たとえば「Draft」から「Submitted for Review」への変更です。この変更とタイムスタンプは、変更履歴またはステータスログのテーブルに記録されます。取得仕訳のステータスフィールドが「Submitted」または同等の値に変更されたことを追跡し、その変更時のタイムスタンプから算出します。イベントタイプ inferred
	仕訳の確認を開始	このアクティビティは、確認担当者が提出された仕訳の確認を開始した時点を示します。Workivaの作業リストで確認タスクを「開く」または「引き受ける」操作から推定できます。
重要な理由このアクティビティにより、仕訳がキューで待機していた時間と、実際に確認されていた時間を区別できます。確認担当者の作業量を正確に測定し、キューのボトルネックを特定するうえで重要です。入手先多くの場合、明示的なイベントとしては記録されません。システムがタスクを特定のユーザーに割り当てた時点、または提出後にユーザーが初めて仕訳レコードを開いた時点から推定できます。取得タスクのステータスが「In Progress」に変更された時点、または提出後に割り当てられた確認担当者が初めてレコードを開いた時点から推定します。イベントタイプ inferred
	仕訳を修正	却下後、作成者または別のユーザーが指摘された問題に対応するため、仕訳を修正します。通常、明示的なイベントではなく、「Rejected」ステータスの後にレコードのデータが変更されたことから推定します。
重要な理由このアクティビティは手戻りループの重要な一部です。仕訳の修正にかかる時間を測定することで、エラーへの対応速度や、特定のユーザーまたは仕訳の種類で修正に時間がかかっているかを把握できます。入手先監査証跡ログを分析して推定します。「Rejected」ステータスから再提出までの間に仕訳で発生した項目変更イベントを探して特定します。取得「Rejected」イベントのタイムスタンプ後に仕訳データが変更されたことを示す変更ログまたは監査証跡から特定します。イベントタイプ inferred
	仕訳を承認に回す	初回確認が完了すると、仕訳は指定された承認者または承認グループへ正式に送られます。たとえば「Reviewed」から「Pending Approval」へのステータス変更として記録されます。
重要な理由このアクティビティにより、初回確認と最終承認の工程を区別できます。これらは異なる役割の担当者が実施する場合があるため、上位承認段階に固有の遅延を切り分けるのに役立ちます。入手先仕訳レコードのステータス変更から推定し、変更履歴テーブルに記録します。ステータスは確認状態から承認状態へ移行します。取得ステータスフィールドが「Pending Approval」または同等の値に変更されたことと、そのタイムスタンプを追跡して算出します。イベントタイプ inferred
	仕訳を照合	この転記後のアクティビティは、照合プロセスで仕訳が一致し、消し込まれた時点で発生します。Workivaの照合または勘定科目認証ツール内で記録されます。
重要な理由転記から照合までの時間を分析することは、決算プロセスの効率を把握するうえで重要です。この段階の遅延は、財務報告の適時性と正確性に影響する可能性があります。入手先通常、Workiva内の別の照合モジュールまたはテーブルから取得します。照合済みの項目と元の仕訳IDが関連付けられ、照合ステータスが変更された時点のタイムスタンプを使用します。取得照合モジュールで仕訳が「Reconciled」として記録されたイベントまたはステータス変更のタイムスタンプです。イベントタイプ explicit
	仕訳を確認	このイベントは、確認担当者が仕訳の評価を完了し、承認に回す、却下するなどの対応を行ったことを示します。通常、その後のステータス変更から推定します。
重要な理由重要な品質チェックが完了したことを示します。確認段階にかかった時間を分析することで、チームの作業量を管理し、確認担当者の教育やプロセス簡素化の機会を特定できます。入手先仕訳のステータスが「In Review」から「Pending Approval」や「Rejected」などの次の状態に変更された時点のタイムスタンプから推定します。取得「Review」状態から次のいずれかの状態へステータスが変更された時点のタイムスタンプです。イベントタイプ inferred
	自動検証に失敗	システムの自動検証チェックでエラーが検出され、仕訳がワークフローを進められなくなります。仕訳のステータスは自動的に失敗または手戻りの状態に変更されます。
重要な理由自動化された品質管理が機能していることを示します。失敗の頻度が高い場合、データ入力に関する構造的な問題や検証ルール自体の問題が考えられ、不要な手戻りループを生む可能性があります。入手先システムログ、または自動検証プロセスによって発生したステータス変更から取得します。仕訳のステータスは「Validation Error」などに変更される場合があります。取得検証ルールが失敗した時点で、システムログまたはエラー状態への自動的なステータス変更として記録されるイベントです。イベントタイプ explicit
	自動検証を実行	提出後の仕訳に対して、項目、合計値、コンプライアンスルールを検証する自動システムチェックを実行します。通常、システムがバックグラウンドで実行し、その記録を残します。
重要な理由データ品質の問題を早期に特定し、後工程での手戻りを減らします。失敗の内容を分析することで、ユーザーに共通する入力ミスや、システム上の案内を改善すべき箇所を把握できます。入手先仕訳ワークフローに関連するシステムログまたは特定の取引ログから取得し、検証ルールの実行を記録します。取得検証エンジンが仕訳データに対して実行された時点で、システムによって記録されます。イベントタイプ explicit
	裏付け書類を添付	このアクティビティは、ユーザーが請求書や契約書などの裏付け書類を1つ以上、仕訳レコードに添付した時点で発生します。通常、Workivaの文書管理機能または添付機能を監視して記録します。
重要な理由このアクティビティを追跡することは、コンプライアンスの監視と遅延の特定に欠かせません。仕訳の作成から書類の添付までの時間が、確認・承認サイクルに影響する大きなボトルネックになる場合があります。入手先 Workivaの文書管理機能に関するログから取得し、特定の仕訳IDにファイルが関連付けられた時点を追跡します。明示的なイベントログを使う場合と、添付リンクの作成日から推定する場合があります。取得ユーザーが仕訳に書類を正常にアップロードまたは関連付けた時点で記録されるイベントです。イベントタイプ explicit

推奨任意

抽出ガイド

Workivaからデータを取得する方法

ステップ

WorkivaでAPI Clientを作成：Workiva Adminコンソールに移動します。組織設定で「API Clients」を開き、新しいOAuth2クライアントを作成します。journals:readやaudittrail:readなど、必要なスコープを付与します。生成されたClient IDとClient Secretは安全に保管します。
Python環境を設定：Python 3.6以降がインストールされていることを確認します。ターミナルでpip install requests pandasを実行し、APIリクエストの送信とデータ処理に必要なライブラリをインストールします。
認証スクリプトを作成：PythonスクリプトにOAuth2認証を処理する関数を作成します。この関数でClient IDとClient Secretを受け取り、Workivaのトークンエンドポイント（例：https://[YourWorkivaDomain].workiva.com/oauth2/v2/token）にPOSTリクエストを送信して、アクセストークンを取得します。
APIエンドポイントを特定：仕訳とその詳細な履歴を取得するREST APIエンドポイントを特定します。主要なエンドポイントはhttps://[YourWorkivaDomain].workiva.com/api/v1/journalsのような形式で、履歴エンドポイントは.../api/v1/journals/{journal_id}/historyのような構成になります。
仕訳一覧を取得：主要な仕訳エンドポイントを呼び出す処理をスクリプトに記述します。クエリパラメータを使い、日付範囲などの条件で絞り込みます。この呼び出しにより、それぞれに一意のIDを持つ仕訳オブジェクトの一覧が返されます。
履歴を順に取得：前の手順で取得した各仕訳をループ処理します。各JournalEntryIdについて、個別に履歴または監査証跡のエンドポイントを呼び出し、関連するイベントの順序を取得します。
生のイベントをアクティビティにマッピング：APIレスポンスの履歴データを処理します。Workiva内部のイベント名やステータス変更を、必要なアクティビティ名に変換するマッピングロジックを作成します。たとえば、「下書き」から「レビュー中」へのステータス変更を、「仕訳レビュー提出済み」アクティビティに変換します。
イベントログの行を作成：マッピングした各イベントについて、最終的なイベントログの1行を表す辞書またはオブジェクトを作成します。JournalEntryId、ActivityName、EventTime、ユーザーなどの必須属性に加え、親仕訳データのJournalEntryAmountや部門など、推奨属性も設定します。
APIのページネーションを処理：ページ分割されたAPIレスポンスを処理するロジックを実装します。レスポンスヘッダーまたは本文にある「next」リンクやページトークンを確認し、指定期間のすべてのデータを取得するまで後続のリクエストを送信します。
データを集約して整形：作成したすべてのイベントログ行を1つのリストにまとめます。このリストをpandasのDataFrameに変換し、最終的な処理を行います。
メタデータ列を追加：DataFrameにSourceSystem列とLastDataUpdate列を追加します。SourceSystemには「Workiva」などの固定値を設定し、LastDataUpdateにはスクリプト実行時の現在のタイムスタンプを設定します。
CSVにエクスポート：最終的なDataFrameをCSVファイルに保存します。ファイルがUTF-8でエンコードされ、プロセスマイニングツールへのアップロードに必要な構成になっていることを確認します。

設定

API認証情報：スクリプトには、Workiva管理コンソールで取得した有効なCLIENT_IDとCLIENT_SECRETを設定する必要があります。OAuth2認証に使用します。
APIエンドポイント：Workiva環境のベースURL（例：https://[YourWorkivaDomain].workiva.com）と、トークン、仕訳一覧、仕訳履歴の各エンドポイントのパスが必要です。
日付範囲：抽出対象を限定するため、START_DATEとEND_DATEを指定します。初期分析では、データ量と分析結果のバランスを考慮し、通常3～6か月の範囲を設定します。
フィルターパラメーター：APIのクエリパラメーターで仕訳を絞り込めるよう、スクリプトを設定できます。一般的なフィルターには、特定の業務領域やプロセスに対象を限定するjournalEntryTypeやdepartmentがあります。
ステータスマッピング：スクリプトにはSTATUS_TO_ACTIVITY_MAPという辞書があり、Workiva APIの生のステータス値をイベントログ用の標準アクティビティ名に変換します。組織で独自のステータスを使用している場合は、カスタマイズが必要になることがあります。
前提条件：APIクライアントを作成するには、管理者権限を持つWorkivaアカウントへのアクセスが必要です。Pythonスクリプトを実行する環境には、requestsとpandasライブラリをインストールしてください。

a サンプルクエリ python

import requests
import pandas as pd
from datetime import datetime
import time

class=class="hl-string">"hl-comment"># --- Configuration Settings ---
class=class="hl-string">"hl-comment"># Replace with your Workiva instance details and credentials
WORKIVA_DOMAIN = class="hl-string">"https://[YourWorkivaDomain].workiva.com"
CLIENT_ID = class="hl-string">"[Your-Client-ID]"
CLIENT_SECRET = class="hl-string">"[Your-Client-Secret]"

class=class="hl-string">"hl-comment"># --- Extraction Parameters ---
class=class="hl-string">"hl-comment"># Define the date range for the journal entry extraction
START_DATE = class="hl-string">"2023-01-01T00:00:00Z"
END_DATE = class="hl-string">"2023-12-31T23:59:59Z"

class=class="hl-string">"hl-comment"># --- API Endpoint Definitions ---
class=class="hl-string">"hl-comment"># Use the correct API version and paths for your instance
TOKEN_URL = fclass="hl-string">"{WORKIVA_DOMAIN}/oauth2/v2/token"
JOURNALS_API_ENDPOINT = fclass="hl-string">"{WORKIVA_DOMAIN}/api/v1/journals"

class=class="hl-string">"hl-comment"># Mapping from Workiva status changes to standardized activity names
class=class="hl-string">"hl-comment"># This may need adjustment based on your specific Workiva workflow configuration.
STATUS_TO_ACTIVITY_MAP = {
    (class="hl-string">'Draft', class="hl-string">'In Review'): class="hl-string">'Journal Entry Submitted for Review',
    (class="hl-string">'In Review', class="hl-string">'Pending Approval'): class="hl-string">'Journal Entry Sent For Approval',
    (class="hl-string">'Pending Approval', class="hl-string">'Approved'): class="hl-string">'Journal Entry Approved',
    (class="hl-string">'Approved', class="hl-string">'Posted'): class="hl-string">'Journal Entry Posted to GL',
    (class="hl-string">'Posted', class="hl-string">'Reconciled'): class="hl-string">'Journal Entry Reconciled',
    (class="hl-string">'In Review', class="hl-string">'Rejected'): class="hl-string">'Journal Entry Rejected',
    (class="hl-string">'Pending Approval', class="hl-string">'Rejected'): class="hl-string">'Journal Entry Rejected'
}

def get_access_token():
    class="hl-string">"""Authenticates with Workiva and retrieves an OAuth2 access token."""
    payload = {
        class="hl-string">'grant_type': class="hl-string">'client_credentials',
        class="hl-string">'client_id': CLIENT_ID,
        class="hl-string">'client_secret': CLIENT_SECRET
    }
    response = requests.post(TOKEN_URL, data=payload)
    response.raise_for_status() class=class="hl-string">"hl-comment"># Raise an exception for bad status codes
    return response.json()[class="hl-string">'access_token']

def fetch_paginated_data(url, headers, params):
    class="hl-string">"""Fetches data from a paginated API endpoint."""
    all_data = []
    while url:
        response = requests.get(url, headers=headers, params=params)
        response.raise_for_status()
        data = response.json()
        all_data.extend(data.get(class="hl-string">'data', []))
        url = data.get(class="hl-string">'metadata', {}).get(class="hl-string">'nextPageUrl') class=class="hl-string">"hl-comment"># Adjust based on actual API response structure
        params = {} class=class="hl-string">"hl-comment"># Subsequent requests use the full URL from nextPageUrl
        time.sleep(0.5) class=class="hl-string">"hl-comment"># Respect rate limits
    return all_data

def map_history_to_activity(event, previous_event, journal_details):
    class="hl-string">"""Maps a single history event to a structured activity record."""
    activity_record = {
        class="hl-string">'JournalEntryId': journal_details.get(class="hl-string">'id'),
        class="hl-string">'EventTime': event.get(class="hl-string">'timestamp'),
        class="hl-string">'User': event.get(class="hl-string">'user', {}).get(class="hl-string">'name', class="hl-string">'System'),
        class="hl-string">'JournalEntryType': journal_details.get(class="hl-string">'type'),
        class="hl-string">'JournalEntryAmount': journal_details.get(class="hl-string">'amount'),
        class="hl-string">'JournalEntryStatus': event.get(class="hl-string">'details', {}).get(class="hl-string">'newValue'),
        class="hl-string">'Department': journal_details.get(class="hl-string">'department')
    }

    event_type = event.get(class="hl-string">'eventType')

    if event_type == class="hl-string">'CREATE':
        activity_record[class="hl-string">'ActivityName'] = class="hl-string">'Journal Entry Created'
        activity_record[class="hl-string">'JournalEntryStatus'] = class="hl-string">'Draft'
        return activity_record

    if event_type == class="hl-string">'ATTACHMENT_ADD':
        activity_record[class="hl-string">'ActivityName'] = class="hl-string">'Supporting Documentation Attached'
        return activity_record

    if event_type == class="hl-string">'REVERSAL_PROCESSED':
        activity_record[class="hl-string">'ActivityName'] = class="hl-string">'Journal Entry Reversal Processed'
        return activity_record

    if event_type == class="hl-string">'VALIDATION_RUN':
        status = event.get(class="hl-string">'details', {}).get(class="hl-string">'status')
        if status == class="hl-string">'SUCCESS':
            activity_record[class="hl-string">'ActivityName'] = class="hl-string">'Automated Validation Run'
        elif status == class="hl-string">'FAILURE':
            activity_record[class="hl-string">'ActivityName'] = class="hl-string">'Automated Validation Failed'
        return activity_record

    if event_type == class="hl-string">'UPDATE' and event.get(class="hl-string">'details', {}).get(class="hl-string">'field') == class="hl-string">'status':
        old_status = event.get(class="hl-string">'details', {}).get(class="hl-string">'oldValue')
        new_status = event.get(class="hl-string">'details', {}).get(class="hl-string">'newValue')
        activity_tuple = (old_status, new_status)
        if activity_tuple in STATUS_TO_ACTIVITY_MAP:
            activity_record[class="hl-string">'ActivityName'] = STATUS_TO_ACTIVITY_MAP[activity_tuple]
            return activity_record
        class=class="hl-string">"hl-comment"># Infer other activities based on status
        if new_status == class="hl-string">'In Review' and previous_event and previous_event.get(class="hl-string">'ActivityName') != class="hl-string">'Journal Entry Submitted for Review':
            activity_record[class="hl-string">'ActivityName'] = class="hl-string">'Journal Entry Review Started' class=class="hl-string">"hl-comment"># Inferred event
            return activity_record

    if event_type == class="hl-string">'UPDATE' and previous_event and previous_event.get(class="hl-string">'JournalEntryStatus') == class="hl-string">'Rejected':
        activity_record[class="hl-string">'ActivityName'] = class="hl-string">'Journal Entry Corrected' class=class="hl-string">"hl-comment"># Inferred event
        return activity_record
    
    class=class="hl-string">"hl-comment"># Fallback for unmapped status changes that might represent a review completion
    if event_type == class="hl-string">'UPDATE' and event.get(class="hl-string">'details', {}).get(class="hl-string">'field') == class="hl-string">'status':
        if event.get(class="hl-string">'details', {}).get(class="hl-string">'oldValue') == class="hl-string">'In Review':
             activity_record[class="hl-string">'ActivityName'] = class="hl-string">'Journal Entry Reviewed' class=class="hl-string">"hl-comment"># Inferred event
             return activity_record

    return None

def main():
    class="hl-string">"""Main function to orchestrate the extraction process."""
    print(class="hl-string">"Starting extraction from Workiva API...")
    try:
        access_token = get_access_token()
        headers = {class="hl-string">'Authorization': fclass="hl-string">'Bearer {access_token}'}
        
        class=class="hl-string">"hl-comment"># Fetch all journal entries within the specified date range
        print(fclass="hl-string">"Fetching journal entries from {START_DATE} to {END_DATE}...")
        journal_params = {class="hl-string">'createdAfter': START_DATE, class="hl-string">'createdBefore': END_DATE}
        journals = fetch_paginated_data(JOURNALS_API_ENDPOINT, headers, journal_params)
        print(fclass="hl-string">"Found {len(journals)} journal entries.")

        event_log = []
        last_data_update = datetime.utcnow().isoformat() + class="hl-string">'Z'

        for i, journal in enumerate(journals):
            journal_id = journal.get(class="hl-string">'id')
            print(fclass="hl-string">"Processing journal {i+1}/{len(journals)}: {journal_id}")

            class=class="hl-string">"hl-comment"># Fetch the detailed history for each journal entry
            history_url = fclass="hl-string">"{JOURNALS_API_ENDPOINT}/{journal_id}/history"
            try:
                history_events = fetch_paginated_data(history_url, headers, {})
            except requests.exceptions.HTTPError as e:
                print(fclass="hl-string">"Could not fetch history for {journal_id}: {e}")
                continue

            processed_activities = []
            for idx, event in enumerate(history_events):
                previous_event = processed_activities[-1] if processed_activities else None
                activity_record = map_history_to_activity(event, previous_event, journal)
                if activity_record:
                    activity_record[class="hl-string">'SourceSystem'] = class="hl-string">'Workiva'
                    activity_record[class="hl-string">'LastDataUpdate'] = last_data_update
                    processed_activities.append(activity_record)
            
            event_log.extend(processed_activities)

        if not event_log:
            print(class="hl-string">"No events were generated. The event log is empty.")
            return

        class=class="hl-string">"hl-comment"># Create DataFrame and save to CSV
        df = pd.DataFrame(event_log)
        df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime'])
        df = df.sort_values(by=[class="hl-string">'JournalEntryId', class="hl-string">'EventTime'])
        
        output_filename = class="hl-string">'workiva_journal_entry_event_log.csv'
        df.to_csv(output_filename, index=False, encoding=class="hl-string">'utf-8')
        print(fclass="hl-string">"Extraction complete. Event log saved to {output_filename}")

    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"An API error occurred: {e}")
    except Exception as e:
        print(fclass="hl-string">"An unexpected error occurred: {e}")

if __name__ == class="hl-string">"__main__":
    main()

準備はできましたか？

本日から決算・レポーティング：仕訳プロセスの最適化を始めましょう。このテンプレートには、価値ある分析結果を得るために必要な情報がそろっています。

改善ガイドに戻るテンプレートをダウンロード

本日から決算・レポーティング：仕訳の最適化を開始

仕訳のサイクル時間を30％短縮し、決算を迅速化します。

無料トライアルを開始

クレジットカードは不要です。いつでもキャンセルできます。

決算・レポーティング：仕訳用データテンプレート

決算・レポーティング：仕訳用データテンプレート

決算・レポーティング：仕訳処理の属性

決算・レポーティング：仕訳処理のアクティビティ

抽出ガイド

Workiva REST APIを使ったPythonスクリプトによる抽出

ステップ

設定

a サンプルクエリ python

準備はできましたか？

本日から決算・レポーティング：仕訳の最適化を開始

プライバシーを大切にしています