> ## 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.

# 精算バッチとカレンダー

> 取引が精算エントリとバッチにどうグループ化されるか、各識別子の意味、精算レコードのステータスのタイムラインが示すもの、Balance History が記録する内容とその絞り込み・エクスポート方法、精算カレンダーの国の軸と休日の詳細の読み方を説明します。

[精算サイクルとカレンダー](/docs/ja/support/settlement-cycle-faq)は、資金が**どの日**に着金するかを説明しています。このページは、**取引がどのようにその入金へグループ化されるか**、その結果できるレコードと識別子が何を意味するか、そしてその周辺の元帳とカレンダーをどう読むかを説明します。レポートファイルの内容は[精算ファイル仕様](/docs/ja/support/settlement-file-specification-faq)にあります。

## 取引はどのように 1 回の精算入金へグループ化されますか？

グループ化は 3 階層あり、そのうち貴社が目にするのは外側の 2 つだけです。

| 階層 | グループ化のキー | 貴社に見えるか |
| - | - | - |
| **Pack** | 加盟店 + 取引成功日 + 決済手段 + 注文通貨 + 精算通貨 | **いいえ。** 内部の準備単位のみ |
| **Settlement Entry** | 加盟店 + 注文通貨 + 精算通貨 | はい — バッチ内部の会計単位 |
| **Settlement Batch** | 加盟店 + 精算通貨 + 契約主体 + 清算タイプ | はい — 1 回の精算イベント：貴社への入金とそのレポート |

下から読むと、取引はまず決済手段と取引日ごとにまとめられ、そのまとまりが注文通貨ごとに結合され、さらに精算通貨ごとにバッチへ結合されます。

バッチのキーのうち 2 つの軸は見落とされやすく、どちらも**同じ日に同じ通貨で複数の精算を受け取り得る**ことを意味します。

* **契約主体。** 貴社の取引が複数の Waffo 契約主体のもとで収単されている場合、それぞれが独自のバッチで精算されます。
* **清算タイプ。** 返金Reserve（refund reserve）の取り決めから資金が供給される返金の精算は別の清算ストリームであり、**通常の精算とバッチを共有することはありません**。また休日カレンダーも無視します。[精算サイクルとカレンダー](/docs/ja/support/settlement-cycle-faq)を参照してください。

だからこそバッチは意図的に決済手段、国、注文通貨をまたぎます。また、**1 つの精算日に 2 つの精算通貨があれば 2 つのバッチ**になり、それぞれに独自のファイルが付くのもこのためです。[精算レポートとエクスポート](/docs/ja/support/settlement-reports-faq)を参照してください。

Pack の階層が貴社に関係するのは説明としてのみです。パッキングは決済手段と取引日ごとに行われるため、1 つのバッチが正当に**複数の取引日**をカバーし得ます。精算と取引日が 1 対 1 で対応すると仮定しないでください。

## 精算の識別子は何を意味しますか？

| 識別子 | 形 | 意味 |
| - | - | - |
| Settlement Entry Id | `E` + マーチャント ID + `yyyyMMdd` + 連番 | バッチ内の 1 つの注文通貨の会計単位 |
| Settlement Batch Id | `S` + マーチャント ID + `yyyyMMdd` + 連番 | 1 回の精算イベント。精算ファイル名に含まれる値 |

識別子の中の日付は生成された日付であり、必ずしも資金が動いた日付ではありません。それにはレコード自身の日付フィールドを使ってください。サポートに伝えるべきなのは `S…` の値です。精算とそのファイル、元帳の記録を特定するキーになります。

## 精算レコードのステータスとタイムラインは何を教えてくれますか？

精算レコードにはステータスがあり、その詳細ページには**実行のタイムライン全体**が表示されます。精算は複数回試行され得るため、これは重要です。

| ステータス | 意味 |
| - | - |
| `Created` | 精算の指示が生成されました |
| `Unsettled` | 試行が完了できず、再試行を待っています |
| `Succeeded` | 記帳済み |
| `Failed` | 記帳されずに終了しました |

タイムラインは各イベントを固有のタイムスタンプとともに記録します。生成、失敗した各試行、最終結果です。したがって、実行して失敗し後で成功したレコードは、最後の 1 つだけでなく 3 つすべてを表示します。初期状態のままのレコードは一覧に表示されません。

精算レコードのデフォルトは**直近 90 日**（UTC+8）です。レコードが今日より前の精算日を示していながら未完了であることは正当に起こり得ます。これを生む再試行の順序は[精算サイクルとカレンダー](/docs/ja/support/settlement-cycle-faq)で説明しています。

## Settlement Original Amount と Settlement Target Amount とは何ですか？

| フィールド | 意味 |
| - | - |
| `Settlement Original Amount` | **注文通貨で**合計した精算純額 |
| `Settlement Target Amount` | 同じ資金を精算通貨へ**換算した後**の金額 |

精算契約が注文通貨をその通貨自身へ精算する場合、両者は同一です。換算が関わる場合は異なります。そして `Settlement Target Amount` は**換算が完了するまで空**です。これはデータの欠落ではなく段階です。照合中に target amount が空白であれば、その精算は準備済みでまだ換算されていません。

## Balance History は何を記録しますか？どの business type で絞り込めますか？

Balance History は貴社の**精算口座**の元帳で、精算先のすべての精算通貨を対象とします。絞り込める business type は 6 つです。

| Business Type | 対象 |
| - | - |
| `SETTLEMENT` | 精算から入ってくる資金 |
| `WITHDRAWAL` | 出金の動き。出金の取り消しを含みます |
| `ADJUSTMENT` | 手動の調整 |
| `RESERVE_WITHHOLDING` | Reserveとして留保された金額 |
| `RESERVE_RELEASING` | Reserveの留保が解放されたもの |
| `RESERVE_ADJUSTMENT` | 取り崩されたReserveを精算口座から補充する入金 |

驚かれやすい点が 2 つあります。

* **古い行には、もう生成されないタイプが付いていることがあります。** 換算が出金より前に移る前の FX `Conversion` の行は、今も独自のラベルで表示されます。フィルターは便宜上のものであり、ある行のタイプが存在しなかったことの証明ではありません。
* **Portal の画面は精算口座を表示します。** Reserve口座自体に記帳された動きは、留保と解放用のタブおよび調整用のタブを持つ別の **Reserve Account** ページにあります。API エンドポイント `/api/v1/account/history/inquiry` は 1 回の呼び出しで両方の口座を返します。[精算口座の構造](/docs/ja/support/settlement-account-structure-faq)を参照してください。貴社のアカウントに返金Reserveがある場合、それにも独自の履歴タブがあります。

## Balance History に FX 換算のエントリが表示されなくなったのはなぜですか？

換算が出金時ではなく、資金が精算口座に届く**前**に行われるようになったためです。以下の帰結はすべて意図的なものです。

| 以前 | 現在 |
| - | - |
| 残高は換算前の取引通貨で表示 | 残高は**精算通貨で**表示 |
| 換算が元帳に独自の動きとして現れた | 精算は換算済みで届くため、別途記録するものがない |
| 換算は出金時に行われた | 換算は出金前に完了している |
| 注文通貨ごとに複数のバッチがあり、一部にはレートがなかった | **精算通貨ごとに 1 つのバッチ**で、為替レートは取引ごとに表示 |
| 取引レポートのみ | 精算サマリーレポート**と**精算明細レポート |

過去の記録と比較している場合、古い行に換算の動きがあり新しい行にない理由はこれです。

## Balance History にはどんな列がありますか？エクスポートはどうしますか？

| 列 | 意味 |
| - | - |
| `Account No` | その動きが記帳された口座 |
| `Account Type` | どの口座か |
| `Business Id` | **その動きを引き起こしたものの識別子** — 精算なら精算バッチ ID、出金なら出金注文 ID |
| `Business Type` | 上記のカテゴリ |
| `Direction` | `CREDIT`（入）または `DEBIT`（出） |
| `Amount` / `Currency` | 動きの金額 |
| `Balance` | この動きの**直後**の残高 |
| `Datetime` | UTC+8 |
| `Description` | 何が起きたか。例：`Withdrawal Submission`、`Withdrawal Fee`、`Withdrawal Cancelled` |

`Business Id` は Portal の他の部分へ戻る結合キーです。精算バッチ ID は Settlement Batch へ、出金注文 ID は Withdrawal History へ持っていってください。

| エクスポート | ルール |
| - | - |
| ファイル名 | `account_history_{merchant id}_{from}_{to}.csv` |
| ファイル名のタイムスタンプ | `YYYYMMDDHHMMSS`、UTC+8 |
| 最大の期間 | **31 日** — Portal で制限され、サーバー側でも再度制限されます |

エクスポートは画面上の表と同じ列を持つため、数値の意味が両者の間で変わることはありません。

## デフォルトの期間はどうなっていますか？

| ビュー | デフォルト | 並び順 |
| - | - | - |
| Balance History | 直近 **30 日** | 新しい順。同一タイムスタンプの行は通貨の A–Z 順 |
| 精算レコード | 直近 **90 日** | 最新の精算が先頭 |
| Settlement Batch | 直近 **30 日** | 実際の精算日順、最新が先頭 |

いずれの期間も UTC+8 です。さらに過去まで照合する場合は、明示的にフィルターを広げてください。

## 精算カレンダーが通貨ではなく国で構成されているのはなぜですか？

休日は通貨ではなく国の属性だからです。カレンダーの主たる軸は **Country/Region** で、貴社の有効な契約がカバーする国を ISO 3166-1 alpha-3 コードで列挙し、最初のものが既定で選択されます。ページ上のすべてがその 1 つの選択に従います。

* **Regions of Holidays** は、選択した国/地域の関連国のみを表示し、独立して変更することはできません。
* 取引日と精算日は、繰り延べを含めてその国/地域についてのみ算出されます。
* エクスポートには選択した国/地域のみが含まれます。

**最もよく参照される地域は、アルファベット順より前に一覧の先頭へ固定されています。**

| フィールド | 何か |
| - | - |
| `Transaction Period` | その精算がカバーする取引日 |
| `Scheduled Settlement Date` | 取引がパッキングされた時点で算出された日付 |
| `Scheduled Settlement Date (Deferred)` | その日付がその後移動した場合の日付 — 休日カレンダーの変更や、マイナスの期間が繰り越された場合 |
| `Actual Settlement Date` | 実際に精算された日 |

行は期間の最初の取引日、次に最後の取引日で並びます。エクスポートは `settlement_calendar_[Region]_[YYYYMM].xlsx` を生成し、選択した国/地域がヘッダー行に記載されます。カレンダーには日付ごとのファイルダウンロードはありません。照合用のレポートは精算バッチに属します。

## 特定の日が精算日でないのはなぜですか？

その日をクリックしてください。カレンダーは理由を **Related Holidays** として*国名：休日名*の形で 1 件ずつ列挙します。その日に休業する関連国ごとに 1 行です。これは単なる「Non-settlement Day」のラベルに代わるもので、どの国がなぜ休業したかが正確に分かります。

表示されるのは**確定済み**の休日のみです。検証中の候補の休日は精算を繰り延べず、表示もされません。

営業日の計算には、その契約国について貴社の収単契約にあるすべての**関連国の休日カレンダーを統合・重複排除したもの**を使用します。いずれかが休業していれば、その日は精算日になりません。

## どの国の休日が影響しますか？変更できますか？

2 つのルールが支配します。

1. **一貫性。** 1 つの加盟店と 1 つの契約国について、**すべての決済手段が同じ関連国の集合を持つ必要があります。** 同じ契約国の中で、ある決済手段は休日に繰り延べ、別の決済手段は繰り延べない、という状態にはなりません。これが統合カレンダーを意味あるものにしています。
2. **設定可能性。** どの国の休日を考慮するかは**加盟店ごとに設定されます**。ある市場と関わりのない加盟店が、その市場の休日に繰り延べる理由はありませんし、精算経路が貴社の販売していない市場を必要とすることもあります。繰り延べが貴社のビジネスと合っていない場合は、アカウントマネージャーに相談してください。固定のルールではなく契約の設定です。

カレンダーは常に貴社に実際に適用されている設定を反映するため、そこに表示される統合済みの休日が、貴社の日付を実際に動かすものです。

***

バッチを自社の記録と照合して合わない点がありますか？精算バッチ ID を添えて[サポートにお問い合わせください](mailto:support@waffo.com)。その ID から精算、そのエントリ、ファイル、元帳の記録をたどれます。


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