共通費の配賦計算では、数式が正常に動いたまま符号だけが逆を向くことがある。防ぐ側の設計は 3 つで足りる。①費用と収益の符号規約を 1 つに決め、配賦元・配賦先・差額の 3 系列で統一する ②配賦前後の合計一致など 4 本の検算式を計算シートに常設する ③ロジックを直したら過去分を再計算し、差分ゼロを機械で確認する。監査可能性とは、誰が・いつ・どの式で・どの入力から計算したかを後から辿れる状態を指す。
配賦の検算では、何を先に固めるのか
管理会計における配賦の監査可能性とは、ある部門の配賦後の数値について「誰が・いつ・どの式で・どの入力から計算したか」を後から辿れる状態を指す。手順は、①費用と収益の符号規約を 1 つに決め、配賦元・配賦先・差額の 3 系列で向きをそろえる ②配賦前後の合計一致、配賦率の合計、部門別の符号、前月比の 4 本を検算式として計算シートに常設する ③ロジックを変更したら過去数か月を同じ入力で再計算し、確定済みの値との差分がゼロであることを機械的に確認する、の順である。例外は、組織変更などで配賦基準そのものを変えた月で、この場合の合格条件は差分ゼロではなく「差分がすべて説明できること」になる。
配賦計算のミスが見つけにくいのは、失敗の仕方が静かだからである。参照が切れれば数式はエラーを返すし、桁を間違えれば合計が目に見えて跳ねる。ところが符号の取り違えは、数式が正常に動き、合計欄も何食わぬ顔で数字を返したまま、部門別の内訳だけが逆を向く。スプレッドシートの誤りを分類した研究でも、この種の「動くが正しくない」誤りは、実行時に止まる誤りより発見が遅れることが繰り返し報告されている。
本記事は、共通費の配賦計算に検算と再検証の仕組みを組み込んだ実装から、設計として再利用できる部分だけを抜き出したものである。出典は匿名化した支援案件の実装ログで、観測主体は当社、観測範囲は配賦計算に用いたスプレッドシートと集計処理。業種・組織構造・金額・比率・時期は公開していない。 したがって以下は一般則ではなく、この条件下で有効だった設計の記述である。
符号規約は 1 つに決める — 配賦元・配賦先・差額でそろえる
符号は数式ごとに決めず、データの規約として 1 つに固定する
符号の取り違えは、個々の数式のミスではなく、規約が存在しないことから起きる。まず決めるのは「どちらを正とするか」だけである。管理会計の配賦であれば、費用を正、収益を負とする規約が扱いやすい。決めたら、次の 3 系列すべてで同じ向きを使う。
| 系列 | 何を保持するか | 符号の意味 |
|---|---|---|
| 配賦元 | 配る側に残っている残高 | 正なら費用の分配、負なら戻し（マイナス配賦） |
| 配賦先 | 各部門へ配った額 | 配賦元と同じ向き。部門ごとに反転させない |
| 差額 | 配賦元の残高 − 配賦先の合計 | ゼロ以外は未配分または二重配分の疑い |
ここで重要なのは、符号を「値の中に」持たせ、下流の計算では常に同じ演算を適用することである。値がプラスかマイナスかを都度判定して加算と減算を切り替える設計は、一見すると安全に見えるが、条件分岐が増えるほどデータ上の符号と表示上の符号が混ざり、分岐の条件を書き間違えたときに元の事故が再発する。表示のために正負を反転させたい場合は、計算層ではなく最終段の表示レイヤーで一度だけ行う。
規約は数式の中だけに置かず、シートのヘッダ、集計処理（SQL などデータベースへの問い合わせ）のコメント、配賦台帳の定義欄という、担当者が実際に見る場所すべてに文章で書く。数式の中にしか存在しない規約は、担当が変わった時点で失われる。
数値例 — 正しい式・誤った式・差額
架空の丸い数字による例である。配賦前の部門損益を 1,000、その月の符号付き配賦額を −100（戻し配賦、つまり部門にとっては費用が戻る方向）とする。
| 行 | 式 | 値（例） |
|---|---|---|
| 正しい式 | 配賦後 = 配賦前 − 符号付き配賦額 = 1,000 − (−100) | 1,100 |
| 誤った式 | 配賦後 = 配賦前 − 絶対値(配賦額) = 1,000 − 100 | 900 |
| 差額 | 誤った式 − 正しい式 | −200（配賦額の 2 倍） |
符号を落として絶対値で貼ると、誤差は配賦額そのものではなく 配賦額の 2 倍 になる。100 を足すべきところで 100 を引いているので、ずれは 200 になる。この「2 倍」という性質は、差額を見たときに原因を絞り込む手がかりにもなる。差額が配賦額のちょうど 2 倍であれば、金額の取り違えではなく符号の取り違えを最初に疑ってよい。
検算式は何を常設するのか — 4 本の内訳
検算は「気づいたときにやる作業」ではなく、シートに常設する式にする
検算を手順書に書くと、忙しい月に飛ばされる。式として計算シートの中に置けば、次にシートを開いた人が必ず目にする。常設したのは次の 4 本である。いずれも、条件が成立すればゼロ、しなければ差分を返す式（ブール式）として、計算セルの隣に置く。
| 検算式 | 判定する内容 | 検知できること |
|---|---|---|
| ①配賦前後の合計一致 | 配賦元の残高と、配賦先へ配った額の合計が一致するか | 未配分、二重配分、転記漏れ |
| ②配賦率の合計 | 部門別の配賦率の合計が 1 になるか（丸め許容幅つき） | 部門の追加・廃止時の按分もれ |
| ③部門別の符号チェック | 各部門の配賦額の符号が、配賦元残高の符号と同じ向きか | 絶対値貼り付け、部門単位の符号反転 |
| ④前月比の異常検知 | 配賦率・配賦額の前月比が閾値を超えていないか | 基準変更の見落とし、入力の桁違い |
②の「合計が 1」は丸め誤差との兼ね合いがあるため、許容幅（たとえば小数第 6 位まで）を決めて式に書き込む。許容幅を決めずに厳密一致を求めると、毎月アラートが出て誰も見なくなる。
同時に、この 4 本で何が検知できないかも明示しておく必要がある。①が有効なのは、比較する 2 つの値が別経路・別集計で得られている場合に限られる。配賦元の残高と比較先が同じセルを参照していれば、両方が同じ誤った値になるため一致してしまう。③も、全部門が一斉に同じ向きで反転した場合は「そろっている」と判定される。検算式は誤りを減らす仕組みであって、誤りがないことの証明ではない。異常を自動で拾う設計は、監視の設計原則と同じく「壊れたときに気づけるか」を基準に組み立てる。
ロジックを直したら、過去に遡って再計算する
修正の合格条件は「直した」ではなく「過去分の差分がゼロ」
符号規約と検算式を入れると、次に必要になるのが回帰再検証である。回帰テスト（修正後も過去の入力で同じ結果が出るかを確かめる検査）を配賦計算に持ち込むと、手順は 4 段階になる。
- 修正前に確定値を固定する。 過去 N か月（12 か月を目安）の月 × 部門の配賦後の数値を、そのままスナップショットとして別の場所に保存する。入力データも同時に保存する。
- 修正後のロジックで、同じ入力を再計算する。 入力は 1 で保存したものを使う。最新データを取り直すと、ロジックの差分とデータの更新差分が混ざって切り分けられなくなる。
- 全セルの差分を機械で取る。 月 × 部門のすべてのセルで差分を計算し、差分ゼロを目視やサンプリングではなく式で判定する。経営報告に使う数値である以上、抜き取り検査で足りる場面はほとんどない。
- 差が出たセルを 3 つに分類する。 (a) 今回直した誤りの是正、(b) 意図していない副作用、(c) 配賦基準の変更による説明可能な差。(b) が 1 件でもあれば修正は未完了として扱う。
例外は、組織変更や配賦基準の見直しがあった月である。この月は差分ゼロを合格条件にできないため、代わりに「差分の全件が (a) か (c) に分類され、その理由が書かれていること」を合格条件に置き換える。変更前後で挙動が変わらないことを既知の入力で確認してから本番に出す手順は、ソフトウェア開発では定着している。配賦計算は入力と出力が確定しているため、この検査をそのまま持ち込める。
保存するのは、入力データのスナップショット、実行した式またはクエリ、出力、差分表の 4 点である。この 4 点が揃っていれば、後から「この月の配賦後の数値は、どの入力からどの式で出たのか」に答えられる。監査可能性とは、突き詰めればこの問いに答えられる状態のことで、特別な監査ツールを買うことではない。
「合計は合うのに部門別が逆」はなぜ起きるのか
実装の過程で繰り返し現れた落とし穴を、案件固有の事情を外して整理すると次の 4 つになる。いずれも珍しい事象ではないが、合計欄だけを見ている限り表面化しない。
合計一致だけを検算にしている。 配賦元の残高と配賦先の合計が一致していても、部門間で符号が逆に振られていれば合計は変わらない。合計の一致は必要条件であって十分条件ではないため、部門別の符号チェック（検算式③）を別に持つ必要がある。
戻し配賦（マイナスの配賦）の扱いが決まっていない。 配賦元の残高がマイナスになる月は頻度が低く、運用手順に書かれていないことが多い。頻度が低いということは、起きたときに参照できる前例がないということでもある。符号規約を先に決めておけば、この月も特別扱いせずに同じ式で処理できる。
スプレッドシートの参照ズレ。 行の追加や並べ替えで参照範囲が 1 行分ずれる、コピー時に相対参照が動く、末尾に追加した行が集計範囲から外れる、といった事象である。参照範囲を表として定義し、伸縮が自動で追随する形にしておくと発生率が下がる。
シートと集計処理で規約が二重に実装されている。 同じ配賦をスプレッドシートと集計クエリの両方で計算していると、片方だけ符号規約を直したときに結果が食い違う。どちらを正本にするかを決め、もう一方は正本を参照する形にするのが原則である。
この 3 点セットを入れた案件では、観測期間中、同じ経路での符号の取り違えは再発していない。ただしこれは 1 案件の限られた期間の観察であり、再発率や削減効果を一般化できる根拠ではない。
まとめ — 3 点セットと、それぞれの合格条件
| 仕組み | 目的 | 合格条件 |
|---|---|---|
| 符号規約 | 向きの解釈を担当者ごとに分岐させない | 配賦元・配賦先・差額の 3 系列で同一規約が文書化済み |
| 検算式 | 誤りをその場で見えるようにする | 4 本が計算セルの隣に常設され、許容幅が式に書かれている |
| 回帰再検証 | 修正が過去分を壊していないことを確かめる | 過去 N か月の差分ゼロ、または全差分が説明済み |
配賦の手前にある月次締め後工程（稟議残の突合、マスタ設計、検算の不在）については月次決算の締め後に数字が合わない 4 つの原因で扱っている。
次に読む診断チェック — 自社の配賦シートで 7 項目を確認する
自社の配賦計算にこの 3 点セットが入っているかは、次の 7 項目で判定できる。
- 配賦の符号規約が文章として存在し、シートのヘッダと集計処理の両方に同じ規約が書かれているか。
- 配賦額を絶対値にしてから貼り付けている箇所がないか。符号付きの値をそのまま参照しているか。
- 配賦元の残高と、配賦先へ配った額の合計が一致することを判定する式が、計算セルの隣に常設されているか。
- 配賦率の合計が 1 になることを、丸め誤差の許容幅つきで毎月確認しているか。
- 部門別の配賦額の符号が、配賦元残高の符号と同じ向きにそろっているかを確認しているか。
- 配賦ロジックを直したときに、過去分を同じ入力で再計算して差分ゼロを確認する手順が決まっているか。
- 入力スナップショット・実行した式・出力・差分表を、どこに何か月保存するかが決まっているか。
7 項目のうち 3 つ以上が「確認できない」であれば、配賦計算そのものより先に、符号規約の文書化と検算式の常設に着手した方が結果的に早い。mixednuts では、こうした管理会計の計算設計と検証手順の整備を 戦略・経営管理支援 として提供している。
FAQ
Q. 配賦率の合計が 1 にならないときは、どう扱えばよいか？ A. まず丸めによる差か、按分そのものの漏れかを切り分ける。小数第 6 位程度の許容幅を決め、その範囲内であれば丸め差として最大の配賦先に寄せる。許容幅を超えている場合は、対象部門の追加・廃止・統合が反映されていない可能性が高いので、配賦基準のマスタ側を先に確認する。差を最終セルで無理に埋めると、翌月以降も同じ差が残り続ける。
Q. 戻し配賦（マイナスの配賦）があるときの符号はどう決めるか？ A. 通常月と別の式にしないことが原則である。配賦額を符号付きで保持し、下流は常に同じ演算を適用する設計であれば、戻しの月も式を変えずに正しい値になる。式を分岐させると、頻度の低い戻しの月にだけ通る分岐がテストされないまま残り、そこが事故の起点になる。
Q. スプレッドシートと集計クエリで配賦結果が違うときは、何を先に見るか？ A. 最初に見るのは符号規約で、次が集計範囲、その次が丸めの位置である。差額が配賦額のちょうど 2 倍であれば符号、桁が 10 の冪でずれていれば単位、端数だけの差であれば丸めの位置が原因であることが多い。根本的には、同じ配賦を 2 箇所で実装している状態そのものを解消し、どちらかを正本にしてもう一方が参照する形に変える。
Q. 過去分の再計算で差が出た場合はどうするか？ A. 差が出たセルを、(a) 今回直した誤りの是正、(b) 意図していない副作用、(c) 配賦基準の変更による説明可能な差、の 3 つに分類する。(b) が 1 件でもあれば修正は未完了として扱い、本番へ反映しない。(a) と (c) だけであれば、差分表と分類の根拠を添えて反映する。既に経営報告に使った月の数値が変わる場合は、訂正の要否と報告先を先に決めてから反映する。
Q. 差額が出たとき、誰がどの閾値で止めるのかはどう決めておくか？ A. 検算式ごとに、許容幅、超過時の確認担当、通知先、締めを止める閾値の 4 点を事前に決めて台帳に書く。閾値を決めずに「差が出たら相談」にすると、締め直前の差額はほぼ確実に見送られる。あわせて、超過時に締めを止める判断を誰が行うかを 1 人に定めておくと、月末の判断が滞らない。
Q. 監査対応では、配賦について何を残しておけばよいか？ A. 入力データのスナップショット、実行した式またはクエリ、出力、差分表の 4 点である。この 4 点があれば、ある月の配賦後の数値について「どの入力から、どの式で、いつ、誰が計算したか」を再現できる。保存期間は社内の文書保存規程に合わせ、少なくとも同一年度の比較が可能な長さを確保しておく。
参考文献 / Sources
スプレッドシートの誤りと分類:
- Panko, R. — Spreadsheet Errors: What We Know. What We Think We Can Do[1] — 実行時に止まらない誤りが発見されにくいことの整理
- Rajalingham, K. et al. — Classification of Spreadsheet Errors — 転記・参照・定義の誤りの分類体系
自動検知と回帰検証の設計:
- Google SRE Book — Monitoring Distributed Systems[2] — 「壊れたときに自動で気づける」監視の設計原則
- Google SRE Book — Testing for Reliability[3] — 既知の入力で変更前後の挙動差を確認する回帰検査の考え方
- 12factor.net — Config[4] — 正本データと計算ロジックを分離する設計思想
関連記事:
知見を、事業の実装へ。
60分の無料相談で、貴社に適した論点と次の一手を整理します。