承認したあとに金額を書き換えられる、を止める｜承認証跡と電帳法の真実性確保
承認フローを入れたのに、実は何も止まっていない。そういう状態があります。
上長が承認したあとに、担当者が金額や明細を変更して発行できる。このとき承認の記録は「その時点で見た内容」を証明していません。記録はあるのに、何に対する記録なのかが分からない状態です。
この記事では、なぜこれが起きるのか、どう設計すれば止まるのか、そして電子帳簿保存法の真実性の確保とどうつながるのかを整理します。
標準機能で承認がどこまでできるかはHubSpotで見積の多段承認を組むで扱っています。全体像はHubSpotで帳票を発行・管理する完全ガイドにまとめています。
1. 何が起きているのか
1-1. 承認が「人の行為」として記録されている
多くの承認の仕組みは、誰がいつ承認ボタンを押したかを記録します。ワークフローでタスクを作る方法も、カスタムプロパティのチェックボックスも同じです。
これで足りるように見えますが、記録されているのは行為だけです。その行為が何に向けられていたのかは記録されていません。だから、あとから内容を変えても記録は変わりません。
11月1日：部長が見積（800万円）を承認
11月2日：担当者が金額を1,200万円に変更
11月2日：発行。承認済みの記録は残ったまま
悪意があるケースは稀です。多いのは、客先との交渉で金額が動き、「もう承認はもらっているから」と出してしまうパターンです。仕組みが止めないので、判断が個人に委ねられます。
1-2. 問題になるのは、あとから聞かれたとき
これが表面化するのは、監査や調査で「この金額は誰が承認したのか」と聞かれたときです。承認の記録を出しても、その時点の金額が今の金額と同じだったことを示せません。
内部統制の観点でも同じです。承認プロセスがあること自体ではなく、それが有効に機能していることが問われます。
2. 承認の対象は「人」ではなく「内容」
2-1. 考え方はシンプル
対策の方向は1つです。
承認は帳票の内容そのものに対して行い、内容が変わったらその承認を無効にする。
承認を「人がボタンを押した記録」ではなく、「この内容でよい、という判断の記録」として持ちます。内容が変われば、それは別の帳票なので、承認はやり直しになります。
2-2. 実装の考え方
やることは2つです。申請の時点で帳票内容のハッシュ値（SHA-256など）を保存しておき、発行する時点で再計算して突き合わせる。一致しなければ発行を止めて、再申請させます。
1つだけ注意があります。帳票番号はハッシュの対象から外します。番号は発行時に採るため、申請の時点では決まっていないからです。対象にすると必ず不一致になります。※この段落は設計の考え方に踏み込んだ記述です。公開範囲のご判断をお願いします。
ハッシュを使う利点は、何が変わったかを判定しなくてよいことです。金額だけを見張る実装だと、明細の追加や摘要の書き換えを見逃します。内容全体のハッシュなら、どこが変わっても検知できます。
2-3. どのパイプラインの承認を使うかは、サーバー側で決める
もう1つ、抜け道になりやすい設計があります。適用する承認フローを、画面から送られてきた値で判定してしまうことです。
この作りだと、承認フローが設定されていないパイプラインを名乗ることで、承認そのものを回避できてしまいます。どのフローを適用するかは、取引のデータをサーバー側で取り直して判定します。
HubSpot帳票 法令要件チェックシート（全24項目）
適格請求書の記載事項6項目、消費税額の端数処理、適格返還請求書、電子帳簿保存法の真実性・可視性・検索要件、写しの7年保存まで、条文番号とQ&Aの問番号つきで一覧にしました。
3. 電子帳簿保存法の真実性確保とつながる
承認の話は社内統制の文脈で語られがちですが、保存要件とも接続します。
3-1. 「訂正・削除の記録が残る」という要件
電子帳簿保存法施行規則4条1項は、真実性の確保として4つの措置を挙げ、いずれか1つを満たせばよいとしています。そのうちの3号が「訂正・削除の記録が残るシステム、または訂正・削除ができないシステムで授受・保存すること」です。
承認の仕組みでハッシュを保持していれば、内容が変わったことを検知できます。これは、訂正の事実を把握できる状態の一部になります。承認のための仕組みが、そのまま真実性の確保にも効くという関係です。
3-2. 取消も消さずに残す
同じ考え方は、発行後の取消にも当てはまります。間違えて出した帳票を物理的に削除してしまうと、訂正・削除の履歴が残りません。取消は、履歴を残したステータスの変更として行います。
このとき記録するのは、取り消した担当者・日時・理由の3つです。詳しくはHubSpotに添付したPDFは「原本」なのかで扱っています。
4. 記録すべきこと
承認の記録として残すべきものを整理します。
| 残すもの | なぜ必要か |
|---|---|
| 誰が | 承認者を特定する。代理承認の場合は代理であることも残す |
| いつ | 時系列を追えるようにする。時刻はサーバー側で打つ |
| どの内容に対して | ここが抜けている運用がほとんど。承認時点の内容を特定できるようにする |
| どの段階の承認か | 多段の場合、どの段階が成立したかを個別に残す |
| 無効になった記録 | 内容変更で無効になった承認も消さずに残す。やり直した経緯が追える |
3つ目が核心です。1つ目と2つ目だけなら、たいていの仕組みで記録できます。3つ目があるかどうかが、承認が実効性を持つかの分かれ目になります。
5. 受領の記録と、契約成立の証跡は別物
社内の承認とは別に、取引先側の記録もあります。この2つを混ぜると、必要なときに出せる資料になりません。
5-1. 重さが違う
| 区分 | 性質 | 記録する内容 |
|---|---|---|
| 受領の確認 | 受動的な記録。相手が開いた、落とした、という事実 | 時刻・操作（閲覧／ダウンロード）・アクセス元の情報 |
| 発注の確認 | 能動的な意思表示。「この内容で発注する」という行為 | 上記に加えて、入力された氏名と、同意した文言の本文そのもの |
受領の記録は、あとで「受け取っていない」と言われたときの反論材料にはなりますが、「発注していない」への反論にはなりません。開いたことと発注したことは別だからです。
5-2. 証跡として残すときの2つの注意
発注の確認を証跡として残すなら、設計で気をつける点が2つあります。
1つは、同意した文言をバージョン番号だけでなく本文ごと保存すること。番号だけだと、文言を変えた瞬間に、過去の承諾がどの文言に対するものか分からなくなります。
もう1つは、承諾の時刻をサーバー側で打つこと。相手の端末の時計は信用できません。※この段落は設計の考え方に踏み込んだ記述です。公開範囲のご判断をお願いします。
あわせて、誤クリックと意思表示を区別するために、同意のチェックと氏名の入力の両方を必須にするという作りも有効です。チェックだけだと「間違って押した」という説明が成り立ってしまいます。
まとめ
- 多くの承認は「人がボタンを押した記録」で、何に対する承認かが残っていません。だから内容を変えても記録は変わりません
- 承認は帳票の内容そのものに対して行い、内容が変わったら無効にします。内容全体のハッシュで突き合わせれば、どこが変わっても検知できます
- この仕組みは電子帳簿保存法の真実性の確保とも接続します。訂正の事実を把握できる状態の一部になります
- 受領の記録と発注の確認は別物です。後者を証跡にするなら、同意文言は本文ごと残し、時刻はサーバー側で打ちます
標準機能で承認がどこまでできるかはHubSpotで見積の多段承認を組む、保存側の設計はHubSpotに添付したPDFは「原本」なのかで扱っています。全体像はHubSpotで帳票を発行・管理する完全ガイドをご覧ください。
※ 電子帳簿保存法に関する記述は施行規則（e-Gov）および国税庁の公開情報に基づき、2026年11月5日時点で確認したものです。自社の運用が要件を満たすかの最終的な判断については、顧問税理士・会計士にご相談ください。契約の成立や証跡の取扱いに関する法的な判断については、弁護士にご相談ください。
HubSpot帳票 法令要件チェックシート（全24項目）
電子帳簿保存法の真実性の確保を含む24項目を、条文番号とQ&Aの問番号つきで一覧にしました。判定をプルダウンで選ぶと集計されるExcel形式です。
よくあるご質問
Q. 承認フローを入れているのに、実効性がないとはどういう状態ですか？
上長が承認したあとに、担当者が金額や明細を変更して発行できる状態です。多くの承認の仕組みは「誰がいつ承認ボタンを押したか」を記録しますが、その承認が何に向けられていたのかは記録していません。そのため、あとから内容を変えても記録は変わりません。監査や調査で「この金額は誰が承認したのか」と聞かれたとき、承認の記録は出せても、その時点の金額が今の金額と同じだったことを示せないことになります。
Q. 金額が変わったときだけ再承認にすれば足りませんか？
金額だけを見張る実装だと、明細の追加や削除、摘要の書き換え、支払期限の変更といった他の変更を見逃します。承認の対象は帳票の内容全体なので、どこが変わっても検知できる形にするのが確実です。内容全体のハッシュ値を申請時に保存しておき、発行時に再計算して突き合わせれば、何が変わったかを個別に判定する必要がなくなります。
Q. 承認の記録として、何を残せばよいですか？
誰が・いつ・どの内容に対して、の3つが基本です。多段の場合はどの段階の承認かも個別に残します。1つ目と2つ目はたいていの仕組みで記録できますが、3つ目が抜けている運用がほとんどで、ここが実効性の分かれ目になります。あわせて、内容変更で無効になった承認も消さずに残してください。やり直した経緯が追えるようになります。時刻はサーバー側で打つのが原則です。
Q. 承認の話と電子帳簿保存法は関係ありますか？
つながります。電子帳簿保存法施行規則4条1項は真実性の確保として4つの措置を挙げており、そのうち3号が「訂正・削除の記録が残るシステム、または訂正・削除ができないシステムで授受・保存すること」です。承認の仕組みで内容のハッシュを保持していれば、内容が変わったことを検知でき、訂正の事実を把握できる状態の一部になります。承認のために作った仕組みが保存要件にも効く、という関係です。
Q. 取引先がPDFをダウンロードした記録があれば、発注の証跡になりますか？
なりません。ダウンロードの記録は受動的な記録で、相手が開いた・落としたという事実を示すだけです。「受け取っていない」という主張への反論にはなりますが、「発注していない」への反論にはなりません。発注の意思表示を証跡にするなら、相手の能動的な行為として記録する必要があります。具体的には、入力された氏名と、同意した文言の本文そのものを、時刻とあわせて残します。
Q. 同意文言はバージョン番号で管理すればよいのでは？
番号だけでは足りません。文言を変えた瞬間に、過去の承諾がどの文言に対するものだったか分からなくなるためです。番号と文言の対応表を別に持つ方法もありますが、その表自体の変更履歴を管理する必要が出てきます。承諾のたびに文言の本文ごと保存しておくほうが、あとから説明するときに確実です。あわせて、承諾の時刻はサーバー側で打ってください。相手の端末の時計は信用できません。
Q. 誤クリックと意思表示を、どう区別すればよいですか？
同意のチェックと氏名の入力の両方を必須にする、という作りが有効です。チェックボックスだけだと「間違って押した」という説明が成り立ってしまいますが、氏名を入力する操作が入ると、偶然そうなったとは言いにくくなります。あわせて、同意の対象となる文言が画面上で読める状態になっているかも確認してください。リンク先に置いただけだと、読まずに同意したという主張の余地が残ります。
