> ## Documentation Index
> Fetch the complete documentation index at: https://waffo.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# 精算サイクルとカレンダー

> 精算日の裏側にある運用ルール：UTC+8 の日次締め、決済手段ごとの精算契約、日次 / 週次 / 半月次 / 月次のサイクルタイプと各タイプでの T+N の数え方、統合された祝日カレンダーに基づく営業日への繰り延べ、精算バッチ、ネットがマイナスになる期間、そして繰り延べされない返金 Reserve の精算。

[加盟店精算](/docs/ja/essentials/merchant-settlement) では、提供しているサイクル（T+1、T+10、週次）を説明しています。
このページでは運用面を扱います。**どの**取引が精算に含まれるか、資金が**どの**暦日に着金するか、そして精算日が
資金もファイルもなく過ぎることがあるのはなぜか。レポートの列は
[Reconciliation reports](/docs/ja/developer-docs/tools-and-references/references/reconciliation-reports) で定義されています。

## 精算日はどのように計算されますか？

1. **取引日で範囲を決める。** 精算準備は各暦日の終了後に実行され、**成功時刻**が前日の `00:00:00`〜`23:59:59` **UTC+8** に
   含まれる取引を取り込みます。
2. **契約サイクルを加算し、営業日に着地させる。** T+N サイクルの精算日は **T+N 以降の最初の営業日**です。営業日は
   固定の曜日ルールではなく、祝日カレンダーから決まります。

このため、Portal の Settlement Batch ページの日付フィールドには `(UTC+8)` と表示されています。

## 取引日の合計が、Waffo 側と 1 日ずれるのはなぜですか？

これは最もよくある照合のずれで、次の 3 つのルールでほぼすべてが説明できます。

| ルール | 数字への影響 |
| - | - |
| 日次締めはお客様のローカルタイムゾーンではなく **UTC+8** | UTC-5 の市場での 23:30 の取引は、UTC+8 では*翌*日に属する |
| 範囲は作成時刻ではなく**成功時刻**で決まる | 1 日目に作成され 2 日目に支払われた注文は 2 日目とともに精算される |
| 返金の場合、成功時刻は**返金**の成功時刻 | 古い決済の返金は、元の決済の期間ではなく現在の期間に入る |

## 同じ日の取引が異なる日付に精算されるのはなぜですか？

精算サイクルは加盟店単位の単一の設定ではありません。精算契約は **MID + 決済手段**（および契約国）ごとに設定され、
それぞれが独自のサイクルタイプ（日ベースまたは週ベース）と遅延日数 **N**、独自の精算通貨、独自の精算先アカウントを持ちます。
同じ日に使用された 2 つの決済手段 — または 2 つの国で使用された同じ決済手段 — が、異なる日付・異なる通貨で精算されるのは
正当な動作です。

## 私の契約はどの精算サイクルになりえますか？

5 つのサイクルタイプがあります。どれに該当するか、およびそれに伴う遅延日数 **N** は、MID と決済手段ごとの精算契約で
設定されます。そのため、決済手段ごとに異なるサイクルになることがあります。

サイクルタイプは 2 つのことを同時に決めます。**どの取引がまとめられるか**と、**遅延をどの日付から数えるか**です。

| サイクルタイプ | まとめられる取引 | N を数え始める日付 |
| - | - | - |
| `DAY` | 1 取引日 | その取引日 |
| `WEEK` | 月曜日から日曜日 | その週を締める日曜日 |
| `HALFMONTH` | 1 日から 15 日、または 16 日から月末 | 15 日、または月の最終日 |
| `MONTH` | 暦月全体 | その月の最終日 |
| `MONTH_1X` | 暦月全体 | **翌**月の最終日 |

上記のルールと合わせて読んでください。**その日付に N を加算し、その後、営業日ルールが結果を営業日に着地するまで
後ろへ動かします。** つまり `DAY` サイクルの T+N は取引日自体から N 日後、`WEEK` サイクルの同じ N は週が締まってから N 日後です。

混乱の大半を引き起こす 2 つの点：

* **`MONTH_1X` は `MONTH` とまったく同じ取引をまとめます。** 違いは遅延の起点のみです。取引月の月末ではなく翌月の月末から
  数えるため、同じ N でもおよそ 1 か月遅れて支払われます。
* **`DAY` 以外では、1 回の精算が複数日の範囲をカバーします。** これが、カレンダーの `Transaction Period` が単一の日付ではなく
  範囲を示す理由であり、自社の日次合計が精算と 1 対 1 で一致しない理由です。

## どの祝日が精算日に影響しますか？

1 か国のカレンダーではありません。営業日の計算には、その契約国についてアクワイアリング契約に設定された
**すべての関連国の祝日カレンダーを統合・重複排除したもの**が使われ、週末も含まれます。いずれかの関連国が休業日であれば、
その日付は精算日ではなく、精算は繰り延べられます。

Portal のカレンダーで非精算日をクリックすると、単なる「Non-settlement Day」のラベルではなく、理由が **Related
Holidays**（*国 + 祝日名*）として 1 件ずつ表示されます。確定した祝日のみが表示されます。

## 精算カレンダーはどのように読み、エクスポートすればよいですか？

カレンダーの主要な次元は **Country/Region** です。有効な契約がカバーする国の単一選択リストで、ISO 3166-1 alpha-3 コードで
表示され、デフォルトで最初の国が選択されます。すべてがこの選択に従います。

* **Regions of Holidays** には、選択した国/地域の関連国のみが表示されます。
* 取引日と精算日（繰り延べされたものを含む）は、その国/地域についてのみ導出されます。
* 行には **Transaction Period**、**Scheduled Settlement Date**、**Actual Settlement Date** が表示されます。
* エクスポートすると、同じ 3 列を持つ `settlement_calendar_[Region]_[YYYYMM].xlsx` が生成され、選択した国/地域のみを
  カバーします。

カレンダーはスケジュール表示であり、日付ごとのファイルダウンロードは提供していません。照合レポートは代わりに
精算バッチに添付されます。

**Scheduled Settlement Date (Deferred)** が存在するのは、予定日が取引をまとめる時点で計算され、その後も動く可能性があるためです —
祝日カレンダーの変更や、マイナス期間の繰り越しなど。ここには繰り延べ後の結果が入るため、当初の日付と現在の予定日の両方が
確認できます。

## Settlement Batch とは正確には何ですか？

| 単位 | 粒度 | お客様にとっての意味 |
| - | - | - |
| **Settlement Batch** | 加盟店 + 予定精算日 + 精算通貨 | 1 回の精算イベント：お客様に支払われる資金と、その照合レポート |
| **Settlement Entry** | 上記 + 取引通貨 | バッチ内の会計単位 |

バッチは意図的に国、決済手段、注文通貨をまたぎます。そのため、1 つの精算日に**2 つの精算通貨**がある場合、
**2 つのバッチ**が生成され、それぞれが独自の精算詳細とサマリーレポートを持ちます。Settlement Batch 一覧の初期表示は
過去 30 日です。バッチの詳細ページでは、照合レポートと取引レベルのエクスポートを確認できます。

バッチ内では、各取引は固定の 4 ステップの順序で清算されます — ネット金額を再計算する場合に関係します。**注文通貨**で
請求される手数料と税が最初に差し引かれ、残額が**精算通貨**に換算され、次に**他の通貨**で請求される手数料と税が差し引かれ、
残ったものが **Net Settlement Amount** です。

## 精算日が過ぎたのに、資金もファイルもありません。なぜですか？

通常は、その期間のネット金額が**マイナス**だったためです — 返金とチャージバックが決済を上回りました。その場合：

* その日付に資金は動かず、**精算バッチのレコードは作成されません**。これが、デフォルトで精算レポートが生成されない理由でもあります。
* マイナス残高は**繰り越され**、累積ネットがプラスになるまで後続の期間と合算されます。プラスになった精算で支払われます。
* マイナス期間を補うために**お客様の Reserve を引き当てることはなく**、返金も Reserve から資金供給されません。

「精算するものがない」と「ファイル生成に失敗した」を区別するには、すべての予定日にヘッダーのみのプレースホルダーファイルを
生成するようサポートに依頼してください。これは加盟店ごとの設定です。

## 返金 Reserve の取り決めによる返金の精算が、祝日カレンダーを無視したのはなぜですか？

その種類の精算は、意図的に営業日ルールの対象外にされているためです。

**返金Reserve口座**から資金供給された返金 — [返金の資金はどこから来るのか](/docs/ja/support/refund-funding-source-faq) を参照 —
は、通常の精算にネットされません。それらは独自に、独自の精算バッチで、独自の日付に清算されます。

| | 通常の精算 | 返金 Reserve から資金供給された返金の精算 |
| - | - | - |
| 日付の導出元 | 精算契約のサイクルタイプと遅延日数 N | 返金 Reserve の取り決めの**終了日に、取り決めで定められた固定の暦日数を加算**したもの |
| 関連国が休業日のときに繰り延べされるか | **はい** | **いいえ** — 週末や祝日であっても暦日がそのまま適用される |
| 着金先 | その精算通貨の通常の精算バッチ | 独自の精算バッチ |

この例外の理由は、この精算が取引期間の支払いではなく、取り決めの締め処理だからです。その日付はお客様が同意した取り決めによって
固定されているため、各関連市場の祝日で動かしてしまうと締め日が予測できなくなります — これは通常の精算で営業日ルールが
目指すものと正反対です。

照合時にこれを見分ける方法：

* **独立した精算バッチ**であるため、1 つの日付に通常の精算とこの精算の両方が存在することがあります。
* その取引は決済ではなく返金です。
* 精算レコード、およびその精算サマリーと詳細ファイルの `Comments` フィールドに、返金 Reserve 精算であることを示す値が入ります。
  通常の精算ではこのフィールドは空です。

Reserve口座自体が何か、そこでの保留と解放がどのように数えられるかは
[Reserve](/docs/ja/support/reserve-faq) にあります。なお、**ローリング Reserve**の解放日は別の計算であり、
契約に応じて営業日または暦日で数えられます。

## 古い精算がまだ未完了です。再試行はどの順序で行われますか？

未精算アカウントの残高不足で記帳できなかった精算は、後続の精算実行で固定の順序で再試行されます。**最も古い精算日から**、
同じ日付内では**最も金額の大きいものから**、最も小さい未完了の精算さえ賄えなくなるまで続きます。未完了の古い精算より先に
後の日付が処理されることはありません。これが、Portal のレコードで今日より前の精算日が表示されていながら未完了のままになることが
ある理由です。

***

まだ一致しませんか？ 精算バッチ ID または照合中の取引日を添えて
[サポートにお問い合わせください](mailto:support@waffo.com)。


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.