コンテンツにスキップ
法務案件チェックポイント
Esc
↑↓navigate↵open⌘Jpreview
このページの内容

DB・経理系

残高DB設計・複合払いの返金・外注費の支払いで確認すべきこと。あとから直すのが最も高くつく領域

「月末に経理から『DBの残高と帳簿が合わない』と指摘された」「返品処理でポイントとカード返金のつじつまが合わなくなった」「経営企画から失効ポイントの集計を求められたが答えられなかった」「外注先への支払い期日を見落としていた」。こうしたトラブルの多くは、設計段階で経理・会計の視点が欠けていたことに起因します。このカテゴリは他と性質が違い、法令アラートというより設計指針が中心です（同じく経理とつながる領域として開発費・資産系があります）。

そして、このカテゴリはあとから直すのが最も高くつきます。 他の領域なら仕様変更で対応できても、記録していなかった過去のデータは遡って作れません。「先月の付与総額は？」と聞かれた時点でイベントを記録していなければ、答えは永遠に出ませんし、監査でも「この期間に何が起きたか」を証明できません。ただし外注費の支払いだけは例外で、下請法・フリーランス保護新法による「受領から60日以内」という明確な法的期限があります。

こんな設計・状況になっていたら

  • point_balance のような単一カラムを直接 UPDATE して残高を管理している
  • 残高の変化履歴（イベント種別・日時・金額）を記録していない
  • 月次の経理集計に、毎回その場しのぎのクエリを書いている
  • 複合払い（ポイント＋カード）の返金ルールが未定義のまま実装に入ろうとしている
  • 返金の計算式がコードの中にしかない
  • 外注費の受領日を記録していない / 支払い期日の管理がスプレッドシートや担当者の記憶に依存している

機能別の確認事項

実装しようとしている機能 主な確認事項
ポイント・電子マネーの残高DB設計 「残高」ではなく「残高が変化したイベント」を記録する。event_type（charge / earn / use / refund / expire）が経理処理と対応しているか。履歴は Append Only（UPDATE・DELETE禁止）。balance_after を持ち、SUM(amount) の理論残高との突き合わせを日次バッチで検証する。未使用残高の総量を集計できる設計は、資金決済法の1,000万円超の供託判定にも直結する
複合払い（ポイント＋カード）の返金処理 返金ルール（ポイント先返還か比例按分か）は経理・税務の方針で決まる。エンジニアが独自に決めず、実装前に確認する。決まったルールはハードコーディングせず明文化する。二重返金を防ぐ idempotency_key に UNIQUE 制約を設け、通信リトライや重複操作をDB側でも止める
外注費の支払い管理 下請法・フリーランス保護新法による、「受領から60日以内に支払う」義務。デッドラインは検収ではなく受領（received_at）の時点で発生する。「検収後翌々月末払い」は60日を超えうる。50日経過時点でアラートを出す仕組みを自動化する

このカテゴリの勘所

記録していなかった過去は、あとから作れません。 単一カラムの差分更新は「現在の残高はわかるが、なぜその値になったのかを追えない」状態を生みます。経理から「先月のポイント付与総額は？」「失効処理はいつ走ったか？」と聞かれても、イベントを記録していなければ答えようがありません。「残高そのもの」ではなく「残高が変化したイベント」を記録する。これがこのカテゴリすべての出発点です。

履歴テーブルは会計でいう「仕訳帳」に相当します。 一度記録したデータの物理削除やUPDATEは禁止（Append Only）です。誤って付与したポイントの修正も、誤レコードの削除ではなくマイナスの amount を持つ新しいイベント（会計の逆仕訳に相当）として発行します。削除・更新を許すとイベントの連続性が崩れ、監査に耐えられなくなります。同じ理由で、返金ルールのような判断の根拠もコードの中に埋めず、設定テーブルかドキュメントに明文化してください。「なぜこの計算式なのかコードを読んでも不明」な状態は、それ自体が監査上のリスクです。

法的な期限は、運用ではなくシステムで担保します。 「受領から60日以内」の義務があるのに、支払い管理をスプレッドシートや担当者の記憶に依存していると、技術的な監視ができません。うっかりの期日超過が、そのまま法令違反になります。受領日を正確に記録し、期限前に自動でアラートが飛ぶようにしておけば、この種の事故は設計で防げます。

あわせて確認

最終更新 2026年7月19日