法人ギフトの報告書で重要なのは、見栄えのよい合計ではなく、経理担当者が元の記録まで戻れることです。Microsoft Power BIで分析モデルを作る際は、購買の確約、案内の送信、商品の引換、費用の計上、返金を別々の事実として扱います。同じ施策に関係していても、発生時点、責任者、金額の意味は一致しません。本稿では、それらを混ぜずに、財務と運用の双方が使える構成を考えます。
最初に分析の責任範囲を決める
最初の会議では、画面に置くグラフではなく、誰が何を判断するかを決めます。購買担当者は未履行の確約を知りたいのか、施策担当者は案内後の引換を知りたいのか、経理担当者は計上済み費用を照合したいのか。この三つは関連しますが、同じ指標ではありません。発注後に出荷が遅れていることと、請求書がまだ計上されていないことも別の状態です。
一枚の設計書に、対象法人、施策、取引通貨、報告通貨、対象期間、閲覧者、除外条件を書きます。経理は費用と返金の符号、換算方針、計上期間を決めます。運用部門は送信と引換の意味を決めます。分析担当者は変換処理と更新を管理し、情報管理担当者は閲覧範囲を承認します。兼務していても、どの立場で何を決めたかを残してください。
分析モデルは会計帳簿や支払承認の代わりではありません。配送の完了を見て自動的に費用を認識したり、提供元の残高を会社の自由な予算と解釈したりしない設計にします。計上済み金額の正本は、組織が承認した財務システムです。運用データと差がある場合は、理由と担当者が付いた照合案件として扱います。
日本の本社と海外法人が共同で施策を運営する場合、法人、費目、負担部門、施策の四つを区別すると議論しやすくなります。どの予算から支出するかという方針は、法人ギフトの予算配分と合わせて整理できます。本稿はその方針を分析構成に落とすための提案であり、税務や会計処理の個別判断ではありません。配布用のモデルファイルや既製の接続機能があるとは主張しません。
取り込む前にデータ提供の約束を文書化する
入力元は、取り込みやすさではなく、何の事実に責任を持つかで選びます。購買記録は確約と取消を、ギフト運用記録は案内と引換を、財務記録は計上明細と貸方調整を、施策責任者の管理資料は後日の観察結果を提供します。為替レートは経理または資金管理部門が承認したものを使います。取引先の出力ファイルがそのまま自社の帳簿になるわけではありません。
各入力元について、変更されない記録番号、発生日時、修正日時、抽出日時、タイムゾーン、法人、施策番号、通貨、状態を定義します。さらに、削除や取消がどのように通知されるかを確認します。全件の写しを毎回受け取るのか、前回からの変更だけを受け取るのかが曖昧だと、古い行を誤って消したり、同じ行を何度も追加したりします。
「送信済み」の定義は特に重要です。本稿では、運用システムから案内が正常に送出されたことを指します。郵便物の出荷、電子メールの開封、受取人の同意とは分けます。「引換」は商品の選択が完了した状態です。金券の消費や荷物の受領を意味しません。別の意味が必要なら、別の事実表と名称を作り、読者に分かるようにします。
必須列の欠落、同じ番号に異なる内容がある行、解析できない日付、不明な通貨は、受け付けた件数から黙って落とさずに隔離します。原文、拒否理由、提供者、再提出の条件を残します。隔離された金額や件数を示さないと、利用者には不完全な合計が正常値に見えてしまいます。ゼロ件なのか、まだ届いていないのかも区別してください。
小規模で月次の確認だけなら、管理された出力ファイルと担当者による照合で始められます。頻繁な訂正や複数法人を扱うなら、承認された連携や履歴を保つデータ基盤が適します。自動化には監視と保守が必要であり、手作業には交代時の再現性が必要です。どちらも、提供元に存在しない識別子や履歴を作り出してはくれません。
一行の意味を固定し、事実表同士を安易につながない
公式のスター・スキーマ解説では、説明用のディメンションと、一定の粒度を持つファクトを分けています。実装では、各表について「一行は何か」を先に書きます。財務は元の計上明細一件、送信は重複を除いた案内一件、引換は完了した選択一件です。確約の残高を日次で保存する表なら、一行は確約明細と観察日の組合せになります。
この図は本稿の設計例で、製品の接続画面ではありません。財務の正本は承認済み財務システムです。各ディメンションのキーは一意にし、財務明細側の参照を検査します。最初はディメンションからファクトへの単方向の絞り込みで構成すると、金額が増える原因を追いやすくなります。施策名が共通だからといって、請求明細を引換明細に直接結合しないでください。
一つの施策に三つの請求明細と八十件の引換があると、直接結合によって請求明細が繰り返される可能性があります。表示された合計を八十で割って補正するのは対策ではありません。共通ディメンションを通して別々に集計し、必要な比較だけを同じ画面に置きます。配賦が必要な場合は、元明細と配賦明細を分け、比率の合計を検査します。
日付には役割を付けます。計上日は経理期間、送信日は対象群、引換日は作業の発生量を説明します。一月の案内が二月に引き換えられたとき、二月の作業でありながら一月の対象群の結果でもあります。汎用の「日付」だけで全表を絞ると、この違いが画面から消えます。日付の役割が分かる見出しと指標名にしてください。
残高の写しは、指定した一時点だけを比較します。日々の未履行残高を月内で足すと、同じ義務を何度も数えることになります。また、部門変更や法人再編が起きた場合は、発生時点の所属と現在の所属を分けるかを決めます。現在の組織名で履歴を上書きすると、過去の説明ができなくなります。方針を決めてから履歴の持ち方を設計します。
指標辞書に日付、符号、除外条件を残す
メジャーと呼ばれる計算指標は、式だけでは定義できません。対象行、粒度、通貨、日付の役割、除外条件、責任者、適用開始日まで含めて一つの契約です。以下は実装前に関係者が確認するための設計例です。組織の規程を置き換えるものではなく、異なる段階の数字を混同しないための出発点です。
指標辞書：法人ギフト支出モデルの定義、正本、検査する境界。
| 指標 | 定義と正本 | 確認する境界 |
|---|---|---|
| 未履行の確約 | 購買記録による、指定日時の承認済み未履行残高。 | 取消を除き、日次残高を足さない。 |
| 送信数 | 運用記録による、正常に送出した一意の案内数。 | 再送を重複計上せず、荷物は別に数える。 |
| 完了引換数 | 定義した案内対象群に対応する、完了した選択数。 | 未完了の試行を除き、観察期限を示す。 |
| 計上済み返金 | 財務が確認した返金・貸方明細を負数で保持。 | 申請中の返金とは分ける。 |
| 純計上費用 | 対象の財務明細を承認済み報告通貨で符号付き集計。 | 返金を含むため、再度差し引かない。 |
| 対象群の引換率 | 同じ対象群の完了引換数を有効送信数で割る。 | 分母ゼロは率なし。分子と分母を併記する。 |
| 観察された成果 | 施策責任者が承認した後続の観察記録。 | 関係と期間を示し、増分効果と断定しない。 |
確約、請求、支払は同じ義務の別段階であることがあります。全部を足した総額を「総支出」としないでください。前払残高も、返金可能性、用途制限、有効期限を確認せずに「自由に使える予算」と呼ぶべきではありません。元の意味を残し、必要なら財務が承認した別の計算指標を追加します。
複数部門に費用を配るときは、元の計上明細を変更せず、配賦先、比率、承認者、規則の版を別表に保存します。対象となる元明細ごとの比率は合計一です。各部門の数字を足したときに元の費用へ戻ることを確認します。未配賦を隠して均等割りするより、未決定として見える状態にした方が、責任ある判断につながります。
定義が変わったら、過去との比較方法も決めます。送信を「送出」から「到達」に変更すると、分母が変わるため引換率も変化します。それは必ずしも施策の改善ではありません。旧定義を残して比較するか、承認を得て履歴を再計算し、変更点を表示します。式の更新だけで済ませず、見出し、説明文、出力列も同時に整えます。
通貨換算と訂正の証拠を切り離さない
取引通貨と元金額は、最終画面が円だけでも保持します。換算に使ったレート、日付、方向、出所、方針の版も残します。「取引通貨一単位当たりの報告通貨額」なら乗算、逆方向なら除算です。単に「レート」と書かれた列に頼らず、単位を説明できる状態にします。円と米ドルとウォンの原金額を合計して一つの通貨記号を付けてはいけません。
用途に適合する財務承認済みの換算値がある場合は、その値と原通貨を照合できるようにします。分析用の換算を別に行う場合は、帳簿の金額と区別します。欠けたレートを一とみなす、空欄を加算対象から外したまま完全な合計として表示する、といった処理は避けます。換算できない範囲を明示するか、対象指標の公開を止めます。
訂正方法は一貫させます。元システムが同じ番号の最新状態を返すなら、定義した規則でその行を更新します。調整取引を返す方式なら、原取引と符号付き調整を保持します。両方の方法を重ねると、取消が二重に反映されます。元の発生日時、修正日時、取り込み日時を残すことで、後着データの意味を説明できます。
丸めの位置も財務が決める項目です。各行を換算してから丸める方法と、集計してから換算する方法は、端数が一致しないことがあります。許容差、その理由、承認者をテスト記録に含めます。閉じた期間の修正は、過去を改訂するのか、当期の調整として見せるのかを明文化します。グラフの都合で期間を動かすことは避けてください。
承認や購入証拠の取得がまだ整理されていないなら、企業ギフトの承認業務を先に確認すると、分析側の不足が見えやすくなります。分析モデルは存在する承認を参照するもので、後から承認を作ったように見せるものではありません。費目、税務、給与、雇用に関する判断は、それぞれの責任者に残します。
小さな計算式を固定した入力で検査する
以下はモデル計算用の言語である DAXの例です。財務明細には、重複を除いた対象内の計上行だけが入り、各行に承認済み報告通貨額があるとします。返金の符号は負です。これらの前提を満たすかを先に検査し、式を貼り付けるだけで正しくなるとは考えないでください。
純計上費用 =
SUMX ( '財務明細', '財務明細'[符号付き報告通貨額] )
計上済み返金 =
CALCULATE (
[純計上費用],
'財務明細'[明細区分] = "返金"
)
対象群引換率 =
DIVIDE ( [対象群完了引換数], [対象群有効送信数] )
行ごとの集計関数は各行の式を評価し、計算範囲を変える関数はここでは返金区分を選びます。除算関数は分母ゼロで空白を返す使い方ができます。返金の指標は区分を固定するため、画面の区分フィルターと組み合わせた結果も検査します。比率の二つの基礎指標は、重複のない対象群から別々に定義します。
最初の入力は三行で十分です。百二十、三十、マイナス二十の明細なら、純額は百三十、返金はマイナス二十です。最初と最後の行だけが属する施策を選べば百になります。八十件の有効送信に六十件の完了引換なら七十五パーセントです。送信ゼロでは率を表示しません。同じ番号を再取り込みしても結果が変わらないことを確認します。
この例は公式関数に基づく構文と期待する算術結果であり、読者の本番環境で実行済みという意味ではありません。実際の関係、権限、日付フィルターを持つモデルで実行し、期待値と実測値を保存してください。さらに不明な施策、欠けた換算額、返金の取消、閉じた期間の訂正を加えます。全体合計が合っていても、法人別の内訳が正しいとは限りません。
検査の責任を開発担当者だけに閉じないことも重要です。経理は元明細との一致を、運用は対象群の条件を、情報管理担当者は閲覧範囲を確認します。結果が違う場合は、入力、重複、粒度、関係、日付の順に原因を絞ります。説明できない係数を掛けて期待値に合わせる修正は、次の更新で再び破綻します。
仮想事例一：日本法人の百万円枠を照合する
以下は説明のための仮想事例で、実在顧客の成果ではありません。日本法人が顧客向けギフト施策に百万円を承認したとします。対象期間に商品八十万円、送料八万円、計上済みの返金五万円があり、純計上費用は八十三万円です。購買側では、すでに計上した部分を除いた未履行確約十二万円が残っています。
この会社が承認した管理上の見込額を「純計上費用と未履行確約の合計」とするなら、見込額は九十五万円、残りの余裕は五万円です。ただし、確約の十二万円に計上済み部分が含まれていないか、返金が当該施策の費用を減らすものかを経理が確認します。計算が簡単であることと、入力の意味が正しいことは別です。
運用側では百件の有効案内のうち八十件の選択が完了しているとします。引換率は八十パーセントですが、それを費用に掛けて「八割だけ使った」とは言えません。名入れ商品、梱包、送料、固定費には別の契約条件があります。未引換の割合と返金可能な割合を混同しないよう、画面では数量と金額を別の指標群として表示します。
受入証拠には、八十三万円の計上明細一覧、十二万円の未履行一覧、八十件と百件の対象群、各入力元の締切日時を含めます。購買担当者は重複確約がないこと、経理は返金の計上、運用担当者は再送の除外を確認します。受取人の住所を集めなくても、この確認に必要な参照番号と集計は用意できます。
返金五万円が申請中にすぎなければ、純計上費用は八十八万円です。未履行確約と合わせた見込額は百万円で、余裕はありません。申請中の回収見込五万円は別に表示します。申請を計上済みと取り違えると、まだ認められていない五万円を新しい発注に使えるように見せてしまいます。
もう一つの失敗は、八十三万円にすでに含まれる返金を再度差し引くことです。返金メジャーがマイナス五万円なら、その値を引くと八十八万円へ戻ってしまいます。修正すべきなのは符号と指標定義です。財務明細を引換件数で増殖させた場合は関係を修正します。どちらも原記録と修正理由を残し、同じ入力で再検査します。
仮想事例二：月をまたぐ引換と閲覧権限を分ける
別の仮想事例として、一月に二百件の有効案内があり、国内法人が百二十件、海外法人が八十件だったとします。二月十日時点の完了は、それぞれ九十件と六十件です。対象群全体では百五十件を二百件で割り、七十五パーセントになります。二月中の完了が三十件であっても、その三十件は月内作業量であり、同じ比率の分子とは限りません。
施策担当者は一月対象群の進捗を、運用管理者は二月の処理量を選びます。案内番号を通して完了を対象群へ結び付け、送信日と引換日を両方保持します。後から完了が増えれば最新の観察値を更新できますが、すでに経営会議へ提出した報告書は元の観察日を残します。新しい結果で古い説明を消さないでください。
国内担当者の閲覧範囲が国内法人に限られるなら、表示される率は九十件を百二十件で割った値です。全社の百五十件と二百件を見せる必要はありません。権限のない利用者は行を取得できず、承認された本社の確認者は全体を閲覧できるという期待を、それぞれテストアカウントで確かめます。
公式の行レベルセキュリティ説明では、ワークスペースの閲覧者には制限が適用されますが、管理者、メンバー、共同作成者には同じ制限が適用されないことが示されています。開発者の高権限アカウントだけで試して、安全だと結論付けてはいけません。役割と所属の変更後にも確認します。
画面だけでなく、詳細への移動、許可された出力、別の絞り込み条件も試します。列を隠すことやページを消すことは、閲覧権限の代わりではありません。集計値から個人が推測できるような小規模な区分をどう扱うかも、組織の情報管理方針に合わせて決めます。具体的な抑制閾値を開発者が独断で作らないようにします。
所属が変わった受取人の履歴は、さらに別の判断です。この事例では対象群の分析に送信当時の法人を使いますが、現在誰が見られるかは情報管理担当者が決めます。歴史的な帰属と現在の権限を同じ列で無理に処理しないでください。権限を直すために過去の費用配賦を変える必要はありません。
更新と照合を同じ運用周期で管理する
公式のデータ更新説明では、取り込んだモデルのデータ更新と、画面の再表示が区別されています。ブラウザーを開き直しただけで、新しい返金明細が取り込まれたとは限りません。入力元の締切、取り込み完了、モデル更新完了を別々に表示し、利用者が情報の古さを判断できるようにします。
頻度は判断の必要性から決めます。月次の費用管理なら日次の管理された読み込みで足りることもあり、催事中の例外対応には別の即時性が必要かもしれません。容量、認証情報、必要なゲートウェイ、入力元の交付時刻を実環境で確認します。普遍的な更新回数や即時反映を約束せず、失敗時には最後の受入済み値と古さの警告を示します。
各周期で、受領行数、採用行数、一意の番号数、法人別・通貨別の符号付き金額、不明キー、隔離行、締切時刻を検査します。必要な入力元が一つ欠けただけでも、総額はもっともらしく見える場合があります。到着予定の一覧と照らして完全性を判定し、部分的に公開するなら欠けた範囲と承認者を明示します。
復旧試験には、同じファイルの再処理、重複案内、欠けたレート、閉じた期間への返金、入力列名の変更を含めます。どの条件で停止し、誰が何を直し、何を再確認すれば戻せるかを事前に決めます。正常な更新一回だけでは、訂正や再送に耐えられることを証明できません。少なくとも一つの通常周期と一つの訂正再処理を終えてから対象を広げます。
引継ぎに必要な証拠をそろえる
手順書には、保存場所や更新ボタンの位置だけでなく、最後に受け入れた入力版、元記録への戻り方、差異一覧、再処理の条件、責任者を記します。新担当者が同じ入力で同じ結果を得られるかを確認してください。前任者の記憶がなければ説明できない報告は、まだ安定運用になっていません。
差異は、入力誤り、時間差、方針未決、権限問題、提供元の確認待ちなどに分けます。入力誤りは分析担当者、時間差は運用、方針は経理、権限は情報管理へ渡します。期限が過ぎたことは解決の証拠ではありません。未解決の理由と次の具体的な操作を残し、単なる「確認中」が何週間も続かないようにします。
成果指標の扱いも最後に確認します。ギフト後に面談や更新契約があったとしても、そのすべてをギフトが生んだ増分と呼べません。観察期間、対象群、連結できなかった記録、除外理由を残します。比較設計がない場合は観察された関連として示します。費用が正しく照合できたことと、因果関係が確認されたことは別です。
公開範囲を拡大する前に、経理が指標辞書、運用が事象の意味、情報管理担当者が権限試験を確認し、分析担当者が計算結果と履歴を提出します。別の確認者が元明細から合計を再現できれば、引継ぎの品質を確かめられます。不一致があれば最後の受入版を維持し、影響を受けた項目だけを修正して再検査します。
証拠の構成が決まってから実行基盤を選ぶ
信頼できるモデルは、すべての数字を同じにするものではありません。確約、案内、引換、計上、成果の違いを説明し、各差異に責任者を置くものです。一法人、一施策、一報告通貨から始め、識別子、粒度、日付、符号、権限を検査します。同じ入力と方針から結果を再現できることが、部門横断の共通資料にする条件です。
小さく安定した施策には管理されたファイル運用が適し、入力元と履歴が増えれば統制された連携やデータ基盤が有用になります。Giftpackは、その構成におけるギフト実行基盤の候補として検討できます。利用できるデータ、番号、状態、訂正方法を確認し、標準の Power BI 接続機能があるとは仮定しないでください。財務、税務、給与、個人情報、雇用主としての判断は組織に残ります。承認済みのデータ契約と照合試験を持って導入を相談すると、必要な機能を証拠に基づいて確認できます。