JinJin48
JinJin48
SAP Consultant | BTP · S/4HANA · US Global Rollout
· 15 min read

表紙: SAP FI 支払条件 — 期日、割引、キャッシュフローの連携

SAP FI 支払条件

支払条件は、請求書の支払期日と早期支払に対する現金割引の有無を制御するマスタデータオブジェクトです。これにより、商取引上の合意(「2% 10日、正味30日」など)が、基準日計算、支払期日決定、割引資格に関するシステムで実行可能なロジックに変換されます。SAP FIのすべての請求書(買掛金および売掛金の両方)は、資金の流出または流入のタイミングを決定する支払条件を参照します。


パート 1: 支払条件 — 基本概念(全モジュール)

1.1 支�条件とは

ハブアンドスポーク図:中央に支払条件、それに接続される仕入先請求書、得意先請求書、購買発注、受注伝票、支払実行

Payment Terms(支�条件)は、請求書決済のタイミングルールをコード化したクロスモジュールのマスタデータレコードです。これは、商談(契約条件)、財務計画(キャッシュフロー予測)、および業務実行(支払または回収のタイミング)の交点に位置します。

項目詳細
役割請求書の基準日、正味支払日数、支払割引率、割引期間、分割払いを定義します
使用するモジュールFI(買掛金/売掛金 — プライマリオーナー)、MM(購買発注のデフォルト支払条件)、SD(受注伝票のデフォルト支払条件)、TR-CM(資金管理および支払実行)
トランザクションOBB8(支払条件設定)/ FB60(仕入先請求書入力)/ FB70(得意先請求書入力)/ F110(自動支払プログラム)
主要テーブルT052(支払条件マスタ)/ T052E(支払条件テキスト)/ BSEG(会計伝票明細 — ZTERMフィールド)/ LFA1(仕入先マスタ一般 — デフォルト支払条件)/ KNA1(得意先マスタ一般 — デフォルト支払条件)
S/4HANAに関する注意点支払条件のデータ構造はECCから変更なし。支払ブロックキーロジックと支払割引勘定の決定はカスタマイジングに残存。Fioriアプリ「支払条件管理」はOBB8のモダンなUIラッパーを提供しますが、基盤となるT052ロジックは変更しません。

1.2 支払条件の構造

2x2マトリックス:4つの支払条件タイプ(正味条件、単一割引、複数段階割引、分割払い)の比較

支払条件タイプは、割引構造と分割払いオプションによって異なります。誤ったタイプを選択すると、キャッシュフロー予測や早期支払いの判断が歪められます。

支払条件構造サンプルキーユースケース主要な動作
ネット条件0001早期支払いインセンティブなし。単純な支払期日(例:ネット30日)基準日 + ネット日数 = 支払期日。割引なし。政府機関やコストプラス契約で最も一般的。
単一現金割引00021段階の割引(例:2% 10日、ネット30日)割引期間内に支払われた場合、割引が適用される。最も一般的な商用支払条件。割引勘定はFI-GLで設定する必要がある。
複数段階割引0003段階的割引(例:3% 10日、2% 20日、ネット30日)スライド式割引スケール。仕入先はより高い割引で早期支払いを促進する。一般的ではないが、重要な仕入先のキャッシュフロー支援に有用。
分割払い0004複数回に分けた支払い(例:30日後に33%、60日後に33%、90日後に34%)単一の請求書を複数の支払期日と支払金額に分割する。大規模な設備投資やプロジェクトベースの請求に使用される。分割払いの割合と期間の個別設定が必要。

設計原則: 支払条件は契約交渉およびブループリント中に決定する必要があります。現金割引率はキャッシュフローと運転資本指標に直接影響します。分割払い条件はCFOの承認が必要であり、流動性計画に影響を与えます。


1.3 組織レベルとデータ階層

支払条件の3層参照チェーンを示す階層図: クライアントでのT052定義、ビジネスパートナマスタでのLFA1/KNA1参照、伝票明細でのBSEG有効値

支払条件は、クライアントレベルで一度定義され(T052)、取引先マスタでデフォルトとして参照され(LFA1、KNA1)、伝票明細に有効値として保存されます(BSEG)。ZTERMキーは、定義 → 参照 → 有効値の順に流れます。

Layer 1 — Definition (Client scope)
   │
   └── T052 — Payment Terms Master
          One row per Payment Terms Key (ZTERM).
          Fields: baseline date rule, net payment days,
                  cash discount % and days (1st / 2nd),
                  installment structure.
          Shared across all Company Codes.

Layer 2 — Reference (Business Partner master)
   │
   ├── LFA1 — Vendor Master
   │      ZTERM field = default payment terms for vendor invoices.
   │      Proposed on FB60 / MIRO. Overridable at entry.
   │
   └── KNA1 — Customer Master
          ZTERM field = default payment terms for customer invoices.
          Proposed on FB70 / VF01 billing. Overridable at entry.

Layer 3 — Effective value (Document line item)
   │
   └── BSEG — Accounting Document Line Item
          ZTERM field = effective payment term for this invoice line.
          Sourced from LFA1/KNA1 default, MM Purchase Order, or SD Sales Order;
          overridable at entry.
          Used by F110 (payment program) and F150 (dunning)
          to calculate due dates and discount eligibility.
レイヤオブジェクトテーブルスコープ備考
定義支払条件マスタT052クライアントZTERMキーごとに1行。基準ルール、正味日数、割引率、分割払いを定義。全会社コードで共有。
参照仕入先マスタLFA1仕入先マスタZTERM項目 = 仕入先請求書のデフォルト支払条件。FB60/MIROで提案。
参照得意先マスタKNA1得意先マスタZTERM項目 = 得意先請求書のデフォルト支払条件。FB70/VF01で提案。
有効値会計伝票明細BSEG伝票明細ごとZTERM項目は、請求書明細ごとの有効な支払条件を格納。F110およびF150で使用。

主要な設計判断: 複数の会社コードを持つグローバルプロジェクトでは、単一の共有支払条件セットをT052で管理するか(差異はビジネスパートナのデフォルトで管理)、国別に個別の支払条件を作成するか(例:NT30-US、NT30-JP)を決定します。共有条件はグローバルレポートを簡素化し、ローカライズされた条件は現地財務チームに国固有の現金割引慣行に対する柔軟性を提供します。


1.4 他のマスタデータオブジェクトとの統合

ハブアンドスポーク図:中央に支払条件が配置され、仕入先マスタ、顧客マスタ、税コード、総勘定元帳(現金割引)、銀行マスタに接続

支払条件は単独で機能するわけではありません。これらは買掛金/売掛金の転記ロジック、支払実行、およびキャッシュフロー予測によって使用されます。

オブジェクト関係性実務上の注意点
仕入先マスタ (LFA1)仕入先のデフォルト支払条件仕入先マスタ一般データの支払条件は、すべての仕入先請求書 (FB60、MIRO) で提案されます。購買担当者は購買発注入力時 (ME21N) に、請求書照合担当者は請求書転記時に上書きできます。
顧客マスタ (KNA1)顧客のデフォルト支払条件顧客マスタ一般データの支払条件は、すべての顧客請求書 (FB70) およびSD請求伝票 (VF01) で提案されます。営業担当者は受注伝票 (VA01) で上書きできます。
総勘定元帳 (現金割引)消込のための割引勘定取得された現金割引は、個別の総勘定元帳勘定(通常、買掛金割引取得の場合は6xxxxの費用、売掛金割引付与の場合は4xxxxの収益控除)に転記されます。OBB8または転記キーカスタマイズで設定する必要があります。
税コード現金割引の税務上の影響日本では、現金割引は消費税の計算基準に影響します。割引が取得された場合、税を再計算する必要があります。FI-GL税コード設定 (FTXP) で設定します。
銀行マスタ / 仕向銀行支払実行タイミング支払プログラム (F110) は支払条件を使用して、支払実行日 = 期日 − クリアリング日数を計算します。仕向銀行のクリアリング日数(フロート)は、支払ファイルのリリースタイミングを決定するために支払条件の期日に加算されます。
購買発注 (MM)購買発注の支払条件支払条件は仕入先マスタから購買発注 (ME21N) に提案されます。購買発注の支払条件は請求書 (MIRO) に引き継がれ、異なる場合は仕入先マスタのデフォルトを上書きします。
受注伝票 (SD)受注伝票の支払条件支払条件は顧客マスタから受注伝票 (VA01) に提案されます。受注伝票の支払条件は請求伝票 (VF01) および売掛金請求書 (FB70) に引き継がれます。

パート 2: FI固有のフィールド詳細

2.0 FI(財務会計)の所有範囲

支払条件の設定におけるFI所有権を示すチェックリスト: 識別、基準日、支払期日、現金割引、分割払い

データセクションFI関与備考
識別とタイプ◎ オーナー支払条件キー、説明、勘定タイプ制限
基準日計算◎ オーナー支払期間の開始日(伝票日付、転記日付、入力日付、固定日)
支払期日計算◎ オーナー正味支払日数、日数制限
現金割引設定◎ オーナー割引率と割引期間(最大3段階)
分割払い設定◎ オーナー複数支払請求書の分割払い分割
財務管理との統合○ TR-CMと共有支払ブロックキー、支払プログラム(F110)用の支払方法提案

凡例: ◎ = オーナー/クリティカル、○ = 直接関与


2.1 識別とタイプ

基本支払条件識別フィールドのチェックリスト: 支払条件キー、説明、勘定タイプ、通貨制限

識別フィールドは、支払条件の範囲と使用制限を制御します。

項目説明実務上の使用例
支払条件キー (ZTERM)4桁の英数字コード支払条件の一意識別子。命名規則が重要であり、多くのプロジェクトでは割引体系を示すプレフィックスを使用します(例:N030 = Net 30、D210 = 2% 10日 Net 30)。直感的でないコード(0001、0002)は、常にマスタデータの参照が必要となり、データ入力エラー率が上昇します。
支払条件テキスト短いテキスト説明トランザクションのドロップダウン(FB60、ME21N)に表示されます。簡潔かつ明確でなければなりません。例:「2% 10日、Net 30」は「標準支払条件」よりも優れています。ユーザーはOBB8を開かなくても正しさを確認できるためです。T052Eテーブルによる多言語対応。
勘定タイプ (ZFATR)特定の勘定タイプへの支払条件の使用を制限空白 = 全勘定タイプ許可。K = 仕入先のみ、D = 得意先のみ。誤用を防ぐために使用します。例えば、仕入先に有利な割引条件(3% 10日)は、勘定タイプKに制限し、得意先請求書での使用をブロックします。
日付制限 (ZTDIF)計算のための月の最大日設定すると、基準日がその月の日付を超えるのを防ぎます。例:日付制限15、基準日が6月20日の場合、基準日は7月15日にシフトされます。財務業務における月末支払いの統合に使用されます。公益事業や通信業界以外ではほとんど設定されません。

2.2 基準日付計算

3つの基準日計算方法(伝票日付、転記日付、入力日付)と固定日上書きを示す積層図

基準日は、すべての支払条件計算の開始点です。この項目を誤解すると、買掛金/売掛金と外部取引先との間で支払期日の不一致が発生します。

項目説明実務上の使用例
基準日ルール (ZFAEL)支払期間の開始日を決定する空白 = 伝票日付。1 = 転記日付。2 = 入力日付。3 = 支払条件なし(統計転記用)。伝票日付が標準的な選択 — 仕入先/得意先請求書の請求日と一致し、外部と内部の支払期日計算を一致させます。転記日付は、請求書が請求日から数週間後にバッチで受領される場合(シェアードサービスセンターで一般的)に使用されます。入力日付は稀 — 手動修正シナリオのみ。
固定日 (FXDAY)基準日を設定する月の固定日入力すると、伝票日付/転記日付/入力日付を上書きし、基準日をその月のこの日に設定します。例:固定日 = 15 の場合、6月のすべての請求書の基準日は、伝票日付に関係なく6月15日になります。サブスクリプションや公共料金請求における月末請求統合に使用されます。
追加月数 (ZVABL)ネット日数を適用する前に基準日に加算する月数基準日をNヶ月先にシフトします。例:追加月数 = 1、ネット日数 = 30、請求日 = 6月10日 → 基準日 = 7月10日 → 支払期日 = 8月9日。戦略的仕入先と交渉された長期支払条件(自動車や航空宇宙産業で一般的で、支払条件が90日を超える場合)に使用されます。
評価日ルール外貨請求書の評価日へのリンク為替レートが基準日または支払期日のどちらで固定されるかを決定します。為替差損益の計算タイミングに影響します。設定前にFI-GLチームに相談 — 誤った設定は為替評価に関する監査指摘の原因となります。

2.3 支払期日計算

期日計算フィールドのチェックリスト: 正味支払日数、固定支払日、猶予期間、ブロックキー

支払期日の計算は、請求書の支払時期(買掛金の場合)または回収時期(売掛金の場合)を制御します。このセクションは、キャッシュフローのタイミングと運転資本に直接影響を与えます。

項目説明実務上の使用例
正味支払日数 (ZTAGG)基準日から支払期日までの日数中核項目。例:正味支払日数 = 30、基準日 = 6月10日 → 支払期日 = 7月10日。SAPは支払期日を「基準日 + 正味支払日数」で計算し、「基準日 + 正味支払日数 − 1」ではない(よくある誤解)。DEVでの単体テスト時に実際の請求書で計算を確認すること。
固定支払日支払期日となる月内の固定日正味支払日数の計算を上書きする。例:固定支払日 = 25 の場合、すべての請求書は基準日から翌月の25日が支払期日となる。支払いを統合して実行する業界で使用される(例:建設業の下請け業者への支払いは、請求日に関わらず毎月25日)。現金割引ロジックと競合するため、割引が有効な支払条件ではほとんど使用されない。
猶予期間支払期日経過後、延滞金が発生するまでの追加日数標準T052の項目ではない。督促(F150)および利息計算(OBB1)のカスタマイジングで設定する。軽微な遅延に対する延滞金を防止する。例:猶予期間 = 3日の場合、7月10日支払期日の請求書は7月13日まで督促がトリガーされない。小売業や流通業で一般的。
支払ブロック (SPGRC, SPGRM, SPGRL等)支払実行用のブロックキー技術的には伝票レベル(BSIK/BSAK)に格納されるが、支払条件の設定でデフォルトのブロックキーを提案できる。A = ブロック済、空白 = 支払可能。請求に異議がある場合や仕入先保留に使用される。支払プログラム(F110)はブロックされた請求書をスキップする。支払いを進める前に、手動(FB02またはMIRO経由)でブロックを解除する必要がある。

2.4 現金割引の設定

現金割引構造を示す積層図: 割引率 ステージ1、割引日数 1、割引率 ステージ2、割引日数 2、割引率 ステージ3、割引日数 3

現金割引の設定は、早期支払いのインセンティブ構造を定義します。ここでのエラーは、取引割引が費用/収益勘定に転記されるため、損益計算書(P&L)に直接影響を与えます。

項目説明実務上の使用例
割引率1 (ZBD1P)1番目の割引率例: 2.0 = 割引日数1以内に支払うと2%割引。小数点として格納(2.0であり、0.02ではない)。最も一般的な設定: 単一段階の割引(割引1のみ設定、割引2/3は空白)。多段階割引は、高額な資本財以外では稀。
割引日数1 (ZBD1T)1番目の割引が適用される日数例: 割引日数1 = 10、基準日 = 6月10日 → 割引期限は6月20日。支払プログラム(F110)は、支払日が割引期限以下の場合、自動的に割引を計算する。キャッシュフロー最適化に重要: 財務チームは、資金の滞留を最大化するために、割引期間の最終日に支払うことを目標とすることが多い。
割引率2 (ZBD2P)2番目の割引率(割引1より低い)例: 割引1 = 3%、割引2 = 2%。段階的な早期支払いインセンティブに使用。割引2の適用開始は、割引1の期限切れ後。一般的ではない — 実質的なメリットなく、買掛金/売掛金プロセスに複雑性を追加する。
割引日数2 (ZBD2T)2番目の割引が適用される日数例: 割引日数2 = 20。割引2は基準日から20日後に期限切れ。割引日数1より大きくなければならず、そうでなければシステムが設定を拒否する。
割引率3 (ZBD3P)3番目の割引率(割引2より低い)ほとんど使用されない。例外的な仕入先関係や政府のインセンティブプログラムのためにのみ設定される。3段階割引は、手動の買掛金請求書処理の複雑性のしきい値を超える — ほとんどの買掛金チームは、ハイパーケア期間中に削除を要求する。
割引日数3 (ZBD3T)3番目の割引が適用される日数割引日数2より大きくなければならない。システムは ZBD1T < ZBD2T < ZBD3T < ZTAGG(正味支払日数)を強制する。
割引基準割引計算のための正味金額または総額支払条件レベルではなく、会社コードレベル(OBB8 → 割引基準)で設定される。正味 = 割引は請求書正味金額に適用(税抜)。総額 = 割引は請求書総額に適用(税込)。日本標準は正味 — 消費税は割引対象外。変更前にFIおよび税務アドバイザーに相談すること。

2.5 分割払いの設定

分割払いの構造を示す積層図:分割回数、分割比率、分割期間

分割払い設定は、1つの請求書を複数の支払期日と金額に分割します。これは、設備購入、プロジェクト請求、マイルストーンベースの契約に使用される高度な機能です。

フィールド説明実務上の使用例
分割回数支払分割の総数例:3回の分割は、請求書を3つの個別の支払明細に分割します。システムは、各分割に対してBSEGに個別の明細行を作成します。最大値は通常12です(T052構造で設定可能)。分割支払条件は、現金割引と共存できません。両方が入力されている場合、システムは設定をブロックします。
分割比率1/2/3 (ZPROZ, ZINRT1, ZINRT2)各分割の割合例:分割1 = 33%、分割2 = 33%、分割3 = 34%。割合の合計は100%になる必要があります。システムは設定時(OBB8)にこれを強制します。よくあるエラー:丸め処理により99.99%または100.01%になる場合があります。SAPはこれを拒否します。整数の割合のみを使用してください。
分割日数1/2/3 (ZTAG1, ZTAG2, ZTAG3)各分割の支払期日までの基準日からの日数例:分割日数1 = 30、分割日数2 = 60、分割日数3 = 90。基準日 = 6月10日 → 支払期日 = 7月10日、8月9日、9月8日。大口固定資産購入で、仕入先が段階的な支払いを要求する場合に使用されます。支払プログラム(F110)は、各分割を個別の支払明細として扱います。
分割支払ブロック特定の分割に対するブロックキー標準のT052フィールドではありません。カスタム開発、または請求書転記時(FB60 → 支払タブ → 分割 → 個別分割のブロック)の手動介入が必要です。特定のマイルストーンが達成されず、部分的な支払いが保留されている場合に使用されます。
分割支払分割支払の代替分割支払(SPLT支払条件で設定)により、支払者は設定時ではなく支払時に分割を指定できます。例:今50%支払い、30日後に50%支払い。分割支払よりも柔軟性がありますが、支払プログラム(F110)または支払伝票転記(F-53)での手動入力が必要です。財務運用以外ではほとんど使用されません。

次に読むべきもの

L1) Big Picture

IDCategoryTitle
fi-001OverviewSAP FIとは何ですか?

L2-A) Master Data

IDCategoryTitle
fi-a01OverviewSAP FI マスタデータ:概要、階層、および関係性
fi-a02-01Master DataSAP FI 品目マスタ
fi-a03-01Master DataSAP FI 勘定科目表
fi-a03-02Master DataSAP FI 総勘定元帳
fi-a04-01Master DataSAP FI 支払条件 📍
fi-a04-02Master DataSAP FI 税コード
fi-a06-01Master DataSAP FI 銀行マスタ
fi-a06-02Master DataSAP FI 仕向銀行
fi-a07-01Master DataSAP FI 資産クラス
fi-a07-02Master DataSAP FI 減価償却キー
fi-a07-03Master DataSAP FI 資産マスタ

L2-B) Transaction

IDCategoryTitle
fi-b01OverviewSAP FIトランザクション:プロセスフロー、階層、関係性