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

# 精算アカウントの構造と Account History のフィルター

> 1 つの精算通貨に 2 つの口座番号が表示されるのはなぜか、1 回の出金が 2 件の支払いとして送られるのはなぜか、accountSubType とオーバードラフト限度額フィールドの意味、そして Account History の正しいフィルター値（精算アカウントとReserve口座の両方にわたる 6 つの業務タイプ。Reserve の留保計上、解放、調整を含む）について説明します。

[残高とアカウント履歴](/docs/ja/support/balance-and-account-history-faq) では、各残高の意味と、出金可能額が精算残高より少なくなることがある理由を説明しています。本ページでは、その下にあるアカウントの構造を扱います。1 つの精算通貨に複数の口座番号が表示されることがあるのはなぜか、1 件の出金指示が 2 件の支払いとして着金することがあるのはなぜか、そして Account History が実際に受け付けるフィルター値は何かを説明します。出金 API そのものについては
[出金と残高 API](/docs/ja/support/withdrawal-and-balance-api-faq)
をご覧ください。

## Portal で 1 つの精算通貨に 2 つの口座番号が表示されるのはなぜですか？

精算アカウントは 2 つのサブアカウントに分割できるためで、貴社のアカウントが分割されている場合、Portal には両方が表示されます。各アカウントには `accountSubType` が付いています。

| `accountSubType` | 内容 |
| - | - |
| `REGULATED` | 規制対象サブアカウント |
| `CORPORATE` | 法人サブアカウント |
| `REGULATED_CORPORATE` | **統合**アカウント。両方を 1 つの口座番号で保持し、分割されていません |

3 つのうちどれが貴社に適用されるかはアカウントの設定方法によって決まり、貴社が変更する設定ではありません。理解しておくべき 2 つの結果があります。

* `REGULATED_CORPORATE` の場合、通貨ごとに**1 つ**の口座番号が表示され、すべてが単一の資金プールとして動作します。
* `REGULATED` と `CORPORATE` が別々のアカウントである場合、同じ通貨について**2 行**が表示され、それぞれに固有の口座番号と固有の利用可能残高があります。その通貨における貴社の合計ポジションは両者の合計であり、単一の行にそれが表示されることはありません。

アカウントビューでは、これらは通貨レベルのアカウントに紐づく `subAccounts` リストとして返されるため、`subAccounts` リストが空でない行は親であり、その残高の詳細は子にあります。

## `overdraftLimit` と `availableOverdraftLimit` とは何ですか？

各アカウントにはオーバードラフト（当座貸越）枠が設定されている場合があり、2 つのフィールドで報告されます。

| フィールド | 意味 |
| - | - |
| `overdraftLimit` | そのアカウントに設定されたオーバードラフト枠の総額 |
| `availableOverdraftLimit` | その枠のうち、まだ未使用の金額 |

これらは、何も問題が起きていないのに残高がマイナスになり得る理由を説明するものです。チャージバックとチャージバック手数料は、貴社の残高に対して一定の順序で充当が試みられ、その順序の最後にオーバードラフトを利用することがあり、その後に入金される資金によって解消されます。その順序については [残高とアカウント履歴](/docs/ja/support/balance-and-account-history-faq) をご覧ください。

注視すべき数値は `overdraftLimit` ではなく `availableOverdraftLimit` です。枠は消費されるものであるため、設定された限度額が大きくても現在の余裕については何も分かりません。オーバードラフト枠はアカウント設定の一部であり、セルフサービスで変更できる項目ではありません。ご相談はサポートまでお問い合わせください。

## 1 件の出金申請から 2 件の支払いが発生したのはなぜですか？

資金が両方のサブアカウントから拠出されたためです。これは、貴社の精算アカウントが**統合**（`REGULATED_CORPORATE`）タイプであり、かつ一方のサブアカウントだけでは金額をカバーできない場合にのみ発生します。

| 状況 | アカウントから出ていくもの |
| - | - |
| 規制対象側で全額をカバーできる | **1 件**の支払い。全額が規制対象側から拠出されます |
| 規制対象側に残高がない | **1 件**の支払い。全額が法人側から拠出されます |
| どちらの側も単独ではカバーできない | **2 件**の支払い。まず規制対象側を使い切り、残額を法人側がカバーします |

常に規制対象側が先に引き落とされます。各レグはそれぞれ固有の金額を持つ独立した対外支払いとなるため、貴社の銀行取引明細には 1 件の出金申請に対して 2 件の入金が表示されることがあり、同時に着金しない場合もあります。

\*\*出金手数料は 2 回ではなく 1 回課金されます。\*\*出金が分割される場合、手数料全額は 2 つのレグのうち大きい方に乗り、もう一方のレグには手数料がまったく付きません。したがって、分割された出金を照合する際に、各レグが独立して差額なく一致することを期待しないでください。一方のレグは手数料全額分だけ少なく見え、もう一方は正確に見えます。申請額と比較する前に、両レグを合算してください。

## 残高 API にもサブアカウントは表示されますか？

いいえ。そしてこれが混乱を招く違いです。`/api/v1/account/balance/inquiry` は `accounts[]` に通貨ごとに 1 エントリを返します。

| フィールド | 意味 |
| - | - |
| `accountNo` | 口座番号。グローバルに一意です |
| `currency` | エントリの精算通貨 |
| `totalBalance` | 保有する総残高 |
| `frozenBalance` | チャージバック活動により凍結されている金額 |
| `reserveBalance` | Reserve口座の残高。Reserve が不足している場合はマイナスになり得ます |
| `availableBalance` | 実際に出金できる金額 |

`availableBalance` は保存された値ではなく、導出された値です。

```
availableBalance = totalBalance − frozenBalance − (reserveBalance < 0 ? |reserveBalance| : 0)
```

マイナスの `reserveBalance` は Reserve の不足分であり、その絶対値は Reserve が再び充足するまで出金可能額から留め置かれます。ゼロまたはプラスの `reserveBalance` が `availableBalance` を減らすことはありません。

リクエストで `currency` を省略すると、1 回の呼び出しですべての精算通貨を取得できます。

つまり、API のビューは通貨単位であり、Portal のビューはサブアカウント単位になり得ます。Portal に 2 つの口座番号が表示されるところで API が 1 つしか表示しなくても、どちらも間違いではありません。口座番号ではなく、通貨ごとの合計で照合してください。

## Account History の正しい業務タイプは何ですか？

**6 つ**あり、Portal が提供するフィルターリストは次のとおりです。

| `businessType` | 行が記録する内容 |
| - | - |
| `SETTLEMENT` | アカウントに支払われた精算 |
| `WITHDRAWAL` | アカウントから支払われた出金 |
| `ADJUSTMENT` | 手動の調整 |
| `RESERVE_WITHHOLDING` | Reserve に留保計上された金額 |
| `RESERVE_RELEASING` | 解放された Reserve の留保 |
| `RESERVE_ADJUSTMENT` | 取り崩された Reserve を精算アカウントから回復させる補填 |

スペルにご注意ください。`WITHDRAW` ではなく `WITHDRAWAL` です。

最後の 3 つが重要なのは、Reserve の変動が台帳に表示される形だからです。精算タイプや調整タイプの下に Reserve の活動が見つかることを期待して Account History をフィルターしていた場合は、代わりに `RESERVE_*` の値でフィルターしてください。古い行には、現在は生成されなくなったタイプ（両替が出金より前に移動する以前の FX `Conversion` 行）が残っている場合があるため、すべての変動を突き合わせようとする際は**まずフィルターなしで照会し**、その後絞り込んでください。

## Account History はReserve口座も対象ですか、精算アカウントだけですか？

どの画面・インターフェースを見ているかによります。

| 表示箇所 | 範囲 |
| - | - |
| `/api/v1/account/history/inquiry` | \*\*両方。\*\*すべての API 照会は精算アカウントとReserve口座の両方にわたります。`accountType` を省略すると両方が返されます |
| Portal **Account → Balance → Balance History** | **精算アカウント**。この画面はそのアカウントを照会します |
| Portal **Reserve Account** モジュール | **Reserve口座**。留保、解放、調整が、それぞれ固有の履歴タブとともに表示されます |

アカウントタイプの値は次のとおりです。

| `accountType` | アカウント |
| - | - |
| `MERCHANT_SETTLEMENT` | 貴社の精算アカウント |
| `MERCHANT_RESERVE` | 貴社のReserve口座 |

同じ 2 つの値が `/api/v1/account/history/inquiry` のリクエストと返される各行の両方で受け付けられるため、混在した結果セットの中で Reserve の変動と精算の変動を区別する手段が `accountType` です。行には `accountNo`、`businessId`（変動の原因となった取引）、`amount`、`currency`、`accountDirection`（`DEBIT` / `CREDIT`）、`newBalance`（変動直後の残高）、`transactionTime` も含まれます。

精算アカウントが分割されている場合、Portal のビューではさらに `REGULATED` または `CORPORATE` でフィルターしてサブアカウント単位に絞り込むことができます。統合タイプはフィルターの選択肢にはありません。統合アカウントは 1 つのアカウントであり、絞り込むものがないためです。

## 照会できる日付範囲と、エクスポートできる内容は何ですか？

| 操作 | 制限 |
| - | - |
| `/api/v1/account/history/inquiry` | 1 リクエストあたり最大 **180 日**。`startTime` と `endTime` の両方が必須です |
| Portal の Account History 照会 | 両端が必須。サーバー側の最大ウィンドウはありません |
| Portal の Account History エクスポート | 最大 **31 日**。それより広い範囲はファイル作成前に却下されます |

エクスポートの方が制約が厳しいため、広い範囲を照会してからエクスポートしようとするのではなく、月ごとに区切って照合を計画してください。エクスポートは `account_history_{merchant id}_{from}_{to}.csv` という名前の CSV です。

## 返金の処理手数料はいつ返還されますか？

返金時に元の決済の処理手数料の一部が返還されるかどうかは**契約設定**であり、2 つの状態があります。

| 返金手数料の方針 | 動作 |
| - | - |
| `NO` | 返金時に手数料は返還されません。これが一般的な設定です。 |
| `REFUND_BY_RATIO` | 返金額に比例して手数料が返還されます。 |

`REFUND_BY_RATIO` の場合、返還される手数料は元の注文金額に対する返金額の比率で按分され、貴社の精算通貨の小数精度で**切り捨て**られます。各部分返金は元の注文に対して独立して計算され、常に切り捨てられるため、複数回の部分返金の合計は、1 回の全額返金の場合よりわずかに少なくなることがあります。その差は丸めによるものであり、記録の欠落ではありません。

精算レポートでは、返還された手数料はその期間の手数料合計を減少させます。その数値がどこに反映されるかは [精算レポート](/docs/ja/support/settlement-reports-faq) をご覧ください。

## 返金手数料がまったく返還されませんでした。何が妨げているのですか？

1 つの厳格なルールが適用されます。\*\*決済の手数料通貨と返金の手数料通貨は一致していなければなりません。\*\*一致しない場合、返金に黙ってゼロの手数料返還が付くのではなく、そのバッチの精算処理が失敗して調査対象となるため、解決されるまでその変動は貴社の明細にまったく表示されません。同じチェックにより、元の決済の精算通貨が、それが清算されるバッチの精算通貨と一致することも求められます。

手数料返還を期待していた返金が、ゼロの手数料返還付きで表示されるのではなく精算から完全に欠落している場合、サポートに問い合わせるべきなのはこのチェックです。返金 ID と元の注文 ID をお伝えください。

それ以外では、方針が `NO` の場合は単に手数料返還が適用されません。

## チャージバック手数料は常に USD ですか？

いいえ。チャージバック手数料の通貨は**貴社**の加盟店設定に基づき、各案件で `feeAmount` の隣に `feeCurrency` として返されます。USD に固定されているわけではなく、貴社の精算通貨と一致する必要もありません。

手数料通貨が精算通貨と異なる場合、手数料は**精算時に、その精算固有のレートで**精算通貨に換算されます。案件が開かれた時点で取得されたレートではありません。両者が一致する場合、換算は行われません。チャージバックの元本とチャージバック手数料は別々のレート基準で換算されるため、通貨をまたぐ案件では、金額と手数料が単一のレートを使ったようには見えません。

その結果、明細に予期しない通貨のチャージバック手数料が、換算後の数値と並んで表示されることは正当にあり得ます。結果として生じる精算行のラベル付けについては、
[チャージバック項目リファレンス](/docs/ja/support/chargeback-field-reference)
をご覧ください。


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