対象読者：SAP（主にFI-AP/MM-IV）導入・運用に関わる方／支払条件（OBB8）の設計・テストを任された方
目的：「支払条件の設定の考え方」を整理し、導入時に事故りやすいポイントと、標準では表現しづらくアドオン/運用設計が必要になりやすいパターンをまとめます。
※本記事は一般的なSAP標準機能の理解を目的とした解説です。プロジェクトや会社ごとに要件・統制が異なるため、最終判断は設計方針・会計/購買の運用と合わせて行ってください。
1. 支払条件（Payment Terms）とは何か（超要約）
SAPの支払条件は、主に以下を決めるためのルールです。
- 支払期日（Due Date）：いつ支払うべきか
- 早期支払割引（Cash Discount / Skonto）：何日以内なら何%割引か（段階を持てる）
- （関連）支払プログラム（F110等）での自動支払選定の判断材料
実務的には「請求書を登録したら、いつ支払うことになるのか」を一貫したルールで決めるもの、という理解が重要です。
2. どこで設定する？どこに影響する？（最小構成）
設定（代表）
- OBB8：支払条件の定義（T052）
- ここがメイン。期日・割引条件などの計算ルールを持つ
- （関連）支払プログラム側（例：F110、FBZPなど）
- 「どの銀行口座から」「どの支払方法で」「どの優先度で」払うか等の制御
- OBB8は主に"期日計算"、支払プログラムは主に"支払実行の制御"
影響（代表）
- FIの仕入先請求書（FB60など）
- MMの請求書照合（MIRO）
- 仕入先マスタ（支払条件のデフォルト）
- PO/契約など（購買側で条件を持つ場合）
導入のコツ：支払条件は「APだけの話」ではなく、購買（PO/IV）・受入検収・締処理と密接に結びつきます。
3. OBB8の設計で押さえるべき"計算の材料"
支払期日計算は、概念としてはこう分解できます。
- 基準日（Baseline Date） を決める
- 基準日と支払条件から 支払期日（Due Date） を算出する
- 割引があるなら 割引期限（Discount Deadline） を算出する
ここで一番事故りやすいのが 1)基準日 です。
「請求書日付なのか」「転記日付なのか」「検収日や締日ベースにしたいのか」で結果が大きく変わります。
4. 日本の商習慣で頻出する支払条件パターン（例：締め→支払）
日本のB2Bでよく出る「締め→支払」パターンは、ざっくり以下に集約されます。
- 月末締→翌月末払
- 20日締→翌月末払
- 20日締→翌月20日払
- 月末締→翌月10日/25日払
- 月末締→翌々月末払（サイトが長い）
なぜ「締め」が重要？
多くの企業は「請求書日付がバラバラ」でも、締めでまとめて支払日を決めます。
一方、SAP標準の支払条件は"基準日"を起点に計算するため、締めの概念をどう表現するかが設計の肝になります。
5. OBB8で表現しやすいパターン（テンプレ的に使える考え方）
ここでは、一般に表現しやすい例として 「日限（Day Limit）」 を使うイメージで説明します。
（※実際のフィールド名や見え方はシステム設定・GUI/トランザクション等で差があります）
例1：20日締→翌月末払い（頻出＆表現しやすい）
狙い：当月1〜20は翌月末、当月21〜月末は翌々月末
- 行1：Day Limit = 20 / Fixed Day = 月末 / Additional Months = 1
- 行2：Day Limit = 月末 / Fixed Day = 月末 / Additional Months = 2
テスト例（期待値）
- 基準日：1/10 → 支払期日：2/末
- 基準日：1/25 → 支払期日：3/末
例2：月末締→翌月末払い（最もシンプル）
- 行1：Day Limit = 月末 / Fixed Day = 月末 / Additional Months = 1
例3：月末締→翌々月末払い（サイト長め）
- 行1：Day Limit = 月末 / Fixed Day = 月末 / Additional Months = 2
ポイント：このあたりはテンプレ化しやすいので、導入プロジェクトでは標準テンプレ（カタログ）を用意すると速いです。
6. 事故りやすい：月末締→翌月10日/25日払い（"基準日"次第でズレる）
ここは導入で本当にハマりやすいので、先に結論です。
- 「締め」＝月末
- 「支払日」＝翌月25日（固定日）
- でも 基準日が請求書日付/転記日付のまま だと…
例えば基準日が1/26〜1/31の請求が、計算上「翌月25日」ではなく 翌々月25日 に飛ぶことがあります。
（固定日計算の一般ロジック上、「基準日の"日" > 固定日」だと月繰り上がりが起きやすい）
回避の考え方（いずれか）
- A. 締日基準の運用に寄せる（おすすめ）
- 締処理で基準日（例：ZFBDT）を"締日"に寄せて登録する／転記する
- B. 例外を許容し、取引先の実運用で吸収
- ただし内部統制・支払遅延・取引先トラブルの火種になりやすい
- C. 標準外（アドオン/外部ルール）で制御する
- どうしても「請求書日付起点で締めと固定日支払を厳密に」やりたい場合に検討
導入のコツ：このタイプは「OBB8の数値」だけで片付けず、"基準日をどう運用するか"を必ず設計に含めます。
7. 導入プロジェクトでの注意点（設計・テスト・運用）
7.1 マスタとトランザクションの優先順位を決める
支払条件は複数箇所に存在します（仕入先、PO、請求書など）。
「最終的にどれを正とするか（上書きルール）」が曖昧だと、運用で混乱します。
- 仕入先マスタを基本とするのか
- PO/契約で上書きするのか（取引条件を購買で握るのか）
- 請求書登録時に変更を許すのか（統制）
7.2 "基準日"がどのフィールドに入るか／いつ決まるか
要件が「検収後◯日」「月末締」などの場合、基準日をどこで持つかが重要です。
- 請求書日付（Invoice Date）起点か
- 転記日付（Posting Date）起点か
- 受領日・検収日・締日などを別項目に保持して計算するのか
7.3 休日補正（営業日補正）は別設計になることが多い
「支払日が休日なら前営業日／翌営業日」といった要望は頻出です。
SAP標準で実現できる範囲もありますが、支払プログラム側（銀行営業日・カレンダー・支払媒体）と絡みやすく、OBB8単体で完結しないことが多いです。
7.4 テストは"日付の端"を攻める（これが効く）
支払条件は日付計算なので、テストは端を攻めると不具合が見つかります。
- 1日／締日（15日/20日/月末）／締日の翌日
- 2月末（閏年含む）
- 固定日（10/25など）の前日・当日・翌日
- 休日（連休前後）
- 期跨ぎ（年度末・月末）
最低限のテストケース雛形（例）
- 1/10、1/20、1/21、1/31 で登録 → 期日が想定通りか
- 2/28、2/29（閏年）で登録 → 月末計算が想定通りか
- 固定日10/25の前後で登録 → 月繰り上がりが起きないか
8. "アドオン（または運用設計）が必要になりやすい"パターン
OBB8は強力ですが、万能ではありません。導入でよく出る「標準だけだと厳しい」パターンを挙げます。
（アドオンだけが答えではなく、運用設計・統制・入力ルールで解ける場合もあります）
8.1 基準日が"検収日"や"サービス実績日"で、締めルールも複雑
例：
- 「検収日が当月20日までなら翌月末、21日以降なら翌々月末」
- 「請求書日付はバラバラだが、検収/締めで支払日を確定したい」
→ MM側のプロセス（受入/サービス受領/検収）と連動し、基準日をどう渡すかが肝。
標準で実現するなら「締処理時に基準日を寄せる」等の運用が必要になりがちです。
8.2 取引先・品目・会社コード・拠点によって支払条件が分岐する
例：
- 同一仕入先でも、国内取引と海外取引で支払サイトが違う
- 品目カテゴリや契約種別で支払日が変わる
- 工場Aは15日締、工場Bは20日締…
→ 標準で"持てるところ（契約/PO/仕入先/会社コード）"に整理できれば良いですが、分岐条件が多いとルールエンジン化（アドオン/外部）が検討に上がりやすいです。
8.3 「締め」と「固定日」の組み合わせを"請求書日付起点"で厳密にやりたい
例：
- 月末締で翌月25日払いだが、請求書日付起点で厳密に締めたい
（締処理で基準日を寄せる運用はしたくない）
→ 標準の固定日ロジックとの相性が悪く、例外が出やすい領域。
運用で吸収するか、別ロジックで計算するかの判断が必要です。
8.4 端数処理・手数料負担・海外送金要件が絡む
例：
- 端数が出たら切捨て、ただし取引先Aは切上げ
- 海外送金は支払日を前倒し（着金日を保証したい）
- 銀行都合で支払媒体作成のリードタイムが必要
→ OBB8だけでなく、支払方法・銀行連携・媒体作成プロセスと絡むため、
"支払期日＝送金実行日"ではない設計（前倒し計算）が必要になることがあります。
9. まとめ：支払条件は「設定」ではなく「運用設計」までセット
- OBB8のテンプレ化は非常に効果が高い（特に日本の頻出パターン）
- ただし、導入で事故るのは数値ミスより 基準日・優先順位・締め運用・休日補正 といった"周辺設計"
- 標準で表現しづらい要件は、いきなりアドオンではなく、
- マスタ設計で吸収できないか
- 締処理/入力ルールで吸収できないか
- 支払プログラム側で吸収できないか
- それでも無理ならアドオン/外部ルール
付録：テンプレ化（ツール化）するなら最低限ほしい出力
支払条件テンプレ（カタログ）を作る場合、以下をセットにすると"現場で使える資料"になります。
- 支払条件コード案（命名規則付き）
- OBB8の設定行（Day Limitごとの行セット）
- 期待するビジネス表現（例：20日締 翌月末払）
- 前提（基準日運用）
- 注意事項（ズレが出るケース）
- テストケース（5〜10本：締日前後、月末、2月末、固定日前後）
次回予告（もし続編を書くなら）
- 「支払条件カタログ（日本の商習慣12パターン）」の具体テンプレ集
- 「月末締→翌月25日」の事故をゼロにする設計パターン（運用/統制の型）
- 自動支払（F110）側の設計チェックリスト（FBZPや支払方法との整合）