銀行および決済のインポート

camt.053明細、Stripe CSV、PSP決済消込（reconciliation）、およびカスタムJSONフィード。

すべてのインポートデータは、銀行口座 (bank/accounts/create) における**銀行取引 (bank transactions)**として取り込まれます。取引には externalId が付与されるため、同じファイルの再インポートは安全に行うことができます。すでに存在する (bankAccountId, externalId) の行はスキップされ、skipped カウンターに報告されます。インポートされた取引は初期状態で new ステータスとなり、消込（bank/transactions/match。候補の検索には bank/transactions/suggest-matches を使用）が行われた場合にのみ、総勘定元帳（ledger）に計上されます。

Webアプリでは、同じインポート機能を銀行 (Bank) → ファイルのインポート (Import file)（ファイルアップロード、テンプレート選択）から利用できます。

誤った消込を取り消すには、bank/transactions/unmatch（Webアプリでは銀行 (Bank) → 取引 (Transactions)内の消込解除 (Unmatch)）を使用します。計上済みの仕訳を直接編集または削除することはありません。請求書に消込された決済や、インポートテンプレートによって口座に計上された明細は、すべてのエントリが逆方向になった逆仕訳（reversing journal transaction）が作成されます。日付は date（デフォルトは当日であり、元の計上日より前を指定することはできません）となります。請求書の支払済金額および支払ステータスは、その銀行明細の金額分だけ戻ります。決済代行サービスの決済（settlement）に紐付けられた明細は、決済計上がバッチ単位で行われるため、紐付けが解除されるのみとなります。明細はステータス new に戻り、再度消込を行うことが可能です。逆仕訳の日付は、締まっていない（オープンな）会計期間内である必要があります。

インポートテンプレート (Import templates)

インポートテンプレートは、データソースの指定、ソースが提供するフィールドの一覧、および金額を持つフィールドと総勘定元帳の勘定科目とのマッピングを定義します。テンプレートの管理は、銀行 (Bank) → インポートテンプレート (Import templates) または bank/import-templates/create|update|delete|get|list を介して行います。

POST /v1/bank/import-templates/create
{
  "name": "Stripe payments export",
  "type": "stripe",
  "fields": [
    { "name": "id" },
    { "name": "Created date (UTC)" },
    { "name": "Amount" },
    { "name": "Fee", "accountCode": "6800" },
    { "name": "Amount Refunded" }
  ],
  "metaFields": ["order_id"]
}

type には stripe、iso20022、bank_connection または revolut のいずれを指定します。
各フィールドには name と、オプションで accountCode を指定します。金額を伴うフィールドでのみ勘定科目を指定できます（Stripeの Amount、Fee、Amount Refunded、camt.053の Ntry/Amt、バンキングフィードの transaction_amount.amount）。指定する勘定科目は勘定科目体系（chart of accounts）に存在している必要があります（ledger/accounts/create で作成してください）。
fields は省略可能です。省略した場合、各タイプの標準フィールドリストがデフォルトで使用されます。標準フィールドリストには、Stripeの 決済 (Payments) → エクスポート (Export) ファイルの列（フォームでデフォルト非選択となっている19個の Card … 列を除く）、camt.053のすべての明細に含まれる要素（Stmt/Id、Stmt/Acct/Id/IBAN、Stmt/Bal/…、Ntry/Amt、Ntry/CdtDbtInd、Ntry/Sts、Ntry/BookgDt）、またはPSD2バンキングフィードが取引ごとに返す属性が含まれます。ファイルに合わせてエントリを追加または削除してください。インポート機能は、オプションの camt.053 要素である Ntry/ValDt、Ntry/NtryRef、Ntry/AcctSvcrRef、Ntry/AddtlNtryInf、TxDtls/Refs/EndToEndId、TxDtls/Refs/TxId、TxDtls/RltdPties/Dbtr/Nm、TxDtls/RltdPties/DbtrAcct/Id/IBAN、TxDtls/RltdPties/Cdtr/Nm、TxDtls/RltdPties/CdtrAcct/Id/IBAN、TxDtls/RmtInf/Ustrd、および TxDtls/AddtlTxInf も読み取ります。
Stripeの Customer Email フィールドには "createPartner": true を指定できます。これにより、既存の取引先（partner）に存在しないファイル内のすべてのメールアドレスについて、取引先（個人タイプ、顧客フラグ付き）が自動作成されます。名前には Customer Description（空の場合はメールアドレス）が使用され、ファイルに Card Address … 列が含まれている場合は住所として設定されます。既存の取引先とはメールアドレスで照合され（大文字小文字は区別されません）、作成された数はレスポンスの customersCreated に返されます。
metaFields（Stripeのみ）には、チャージ（charge）が持つメタデータキーのリストを指定します。Stripeは各キーを <key> (metadata) 列としてエクスポートします。このリストは自由記述であり、長くなる場合があります。
invoiceItemId（Stripeのみ、オプション）はカタログアイテムを指定します。これが設定されている場合、インポートによって作成されるすべての請求書（invoice）および貸方伝票（credit note）の明細は、そのアイテム（その計上科目、および invoiceVatRatePercent が空の場合はそのVAT税率）を参照します。明細のテキストは引き続きチャージの内容から取得されます。
companyMetaField（Stripeのみ）は、会社フラグとして使用するメタデータキーのいずれかを指定します。その列の値が true、1、yes、company、business、または b2b である場合、作成される取引先は個人ではなく会社タイプの取引先となります。
invoiceMetaField（Stripeのみ）は注文番号などのメタデータキーを指定し、invoiceVatRatePercent はそれらのキーから作成される請求書のVAT税率を指定します。インポート時に、すべてのチャージおよび返金行はそのキーの値によってグループ化されます：
- 既存の売上請求書（externalRef がその値である受注（sales order）（ecommerce/orders/create、任意のチャネル）、または fullNumber がその値である請求書）に一致する値の場合、そのグループは該当する請求書に紐付けられます。
- 一致する請求書がない値の場合、新しく請求書が作成されます。取引先は Customer Email から取得され（createPartner と同様に、存在しない場合は作成されます）、チャージごとに1行作成されます（Checkout Line Item Summary または Description をテキストとし、チャージ金額を invoiceVatRatePercent に基づくVAT込価格とします）。発行日は最初のチャージ日となり、VATの取扱いは会社情報およびカードの国籍に基づきます。請求書は即座に発行および計上され、チャネルが stripe で externalRef がその値である受注が記録されるため、次回以降のインポートでは新規作成ではなく紐付けが行われます。
- グループ内の各チャージは、入金の計上として請求書に消込され、各返金は返金金額に対する発行済み貸方伝票を請求書に対して作成し、返金との消込を行います。
- 結果の件数は invoicesCreated、invoicesLinked、creditNotesCreated、paymentsMatched として返されます。処理できなかったグループ（顧客のメールアドレスがない、通貨が混在している、紐付け対象の請求書がまだドラフト状態またはすでに全額支払済みであるなど）は warnings にリストされ、new ステータスの銀行取引のまま残されます。同じテンプレート内で Amount を総勘定元帳の勘定科目にマッピングしないでください。請求書に消込されたチャージは二重に計上されませんが、消込されなかったチャージは計上されてしまうためです。
テンプレート名は会社ごとに一意である必要があります。
camt.053およびバンキング接続テンプレートには、Stripeの列の代わりに明細から読み取られる以下の同様のオプションがあります：
- 不明な取引先の自動作成 (Create missing partners): 振替入金側の名前行（TxDtls/RltdPties/Dbtr/Nm、フィードの場合は debtor.name）で createPartner を有効にすると、入金側で未登録の支払人ごとに顧客が作成されます。振替出金側の名前行（TxDtls/RltdPties/Cdtr/Nm、フィードの場合は creditor.name）で有効にすると、未登録の受取人ごとに仕入先が作成されます。取引先は IBAN（partner_bank_accounts に保存されます）によって識別され、次に正確な名前によって識別されます。名前に法形式（UAB、MB、SIA、GmbH、Ltd など）が含まれている場合は会社として、そうでない場合は個人として新規作成されます。作成された数は customersCreated（ファイルインポートの場合）または partnersCreated（フィード同期の場合）として返されます。
- 参照番号による請求書の紐付け (Link invoices by reference): invoiceMetaField に送金情報または参照行（TxDtls/RmtInf/Ustrd、TxDtls/RmtInf/Strd/CdtrRefInf/Ref、TxDtls/Refs/EndToEndId、フィードの場合は remittance_information、reference_number）を設定すると、参照番号、送金情報、または説明に未決済の売上請求書番号（入金）または登録済みの仕入請求書番号（出金）が含まれるすべての新規銀行明細が照合され、支払が計上されます。支払人の IBAN が取引先に保存されている場合、または支払人の名前が取引先の名前やコードと一致する場合、その請求書はその取引先のものである必要があります。不明な支払人からの支払は、請求書の残高と完全に一致し、かつ請求書番号にシリーズ接頭辞が含まれている場合のみ紐付けられます。これにより、金額などの単なる数字を参照番号と誤認することを防ぎます。残高を超える支払は紐付けられません。これらのチェックに失敗した明細は手動での消込のために new ステータスのまま残り、警告（warnings）にリストされます。advanceInvoices: true を指定すると、既知の取引先からの未消込の入金に対して、invoiceVatRatePercent または invoiceItemId の税率に基づく金額で前受請求書（種別 advance）を発行し、支払をそれに消込します。この場合、取引先が既知である必要があるため、債務者（debtor）行も有効にする必要があります。
- 取引コードによる計上ルール (Posting rules by transaction code): Ntry/Amt / transaction_amount.amount の他に、フィールドリストに Ntry/BkTxCd=CHRG、=INTR、=TAXE、Ntry/CdtDbtInd=DBIT、=CRDT（フィードの場合は bank_transaction_code=…、credit_debit_indicator=…）などのルール行を指定できます。明細は、一致する最初のルール（銀行取引コードファミリ、次に取引方向、最後に通常の金額行の順）の勘定科目に計上されます。ルール行はファイル自体の有無とは照合されません。
- 銀行手数料の取引先 (Bank charges partner): …=CHRG ルール行で createPartner を有効にすると、銀行名（明細の Stmt/Acct/Svcr/FinInstnId/Nm、接続元の銀行、または元帳の銀行口座名）を名前とする仕入先が作成され、その手数料がその取引先で記帳されます。
- バンキング接続テンプレートは、各フィード口座に対して bank/feeds/accounts/configure（アプリ内の銀行 (Bank) → 接続 (Connections)）で選択します。これにより syncSchedule（manual、daily、weekly、monthly）も設定され、APIはスケジュールが設定された口座について期間経過後に自動的に同期を行います。テンプレートは bank/feeds/sync ごとに適用され、同期のレスポンスには posted、partnersCreated、invoicesLinked、invoicesCreated、paymentsMatched、および warnings が報告されます。

format の代わりに templateId を bank/statements/import に渡します。テンプレートの type によってパーサーが選択され、ファイルにはテンプレートにリストされているすべてのフィールドが含まれている必要があります。いずれかのフィールドが欠けているファイルは HTTP 422 で拒否され、欠落している列または要素名が返されます。メタデータフィールドの存在は必須ではありません。バンキング接続テンプレートはライブのPSD2フィードを表すため、ファイルインポートには使用できません。

ISO 20022テンプレートはMT940ファイルも読み取ります。{1: または :20: で始まるファイル（または "format": "mt940" で送信されたファイル）はMT940として解析され、テンプレートの参照番号マッチングおよび計上ルールがその行に適用されます。MT940の場合、要素のチェックはスキップされ、MT940にはISO 20022の銀行取引コードが含まれていないため Ntry/BkTxCd=… ルールは適用されません。代わりに Ntry/CdtDbtInd=… ルールを使用してください。

1つの銀行口座は1つの通貨を持ちます。異なる通貨の明細が含まれている場合は HTTP 422 で拒否されます（同じIBANに対して複数の通貨の明細が含まれる camt.053 ファイルの場合、口座の通貨に一致する明細のみがインポートされます）。口座の通貨以外の currency を指定して bank/transactions/import に送信された明細も同様に拒否されます。

accountCode を持つフィールドから生成されたすべての資金移動は、インポート時に1つの仕訳として計上されます。入金の場合は銀行口座の総勘定元帳勘定が借方となり、マッピングされた勘定科目が貸方となります。出金の場合はマッピングされた勘定科目が借方となり、銀行口座の総勘定元帳勘定が貸方となります。金額は移動日の基準通貨に換算されます。その後、銀行取引は該当する仕訳に対して matched（matchedDocumentType = journal_transaction）となり、請求書の消込候補としては提示されなくなります。レスポンスには posted の件数が報告されます。マッピングされていないフィールドからの資金移動は new ステータスのまま残り、従来通り請求書との消込に使用されます。例えば、Fee をPSP手数料の費用勘定にマッピングし、Amount を未マッピングのままにしておくことで、チャージを売上請求書に消込し続けることができます。

POST /v1/bank/statements/import
{
  "bankAccountId": "…",
  "templateId": "…",
  "content": "id,Created date (UTC),Amount,…"
}

ISO 20022 camt.053 (オープンバンキング XML)

リトアニアの銀行（Swedbank、SEB、Luminor、Šiaulių bankas など）では、インターネットバンキングから口座明細を ISO 20022 camt.053 XML 形式でダウンロードできます（通常は明細のエクスポート/ダウンロード画面で、フォーマット「ISO XML」または「camt.053」を選択します）。PSD2口座情報APIからも同じ形式が返されます。

POST /v1/bank/statements/import
{
  "bankAccountId": "…",
  "format": "camt053",
  "content": "<?xml version=\"1.0\"…>…"
}

ファイルには複数の明細が含まれる場合があります。各明細のIBANは銀行口座のIBANと一致している必要があります（IBANを持たない明細や、口座にIBANがない場合はそのまま受け入れられます）。
明細参照番号（AcctSvcrRef/NtryRef、フォールバックとしてコンテンツのハッシュ）が externalId となります。
レスポンスには明細ごとのメタデータ（明細ID、期間、期首/期末残高、取引件数）が返されます。
消込のために、取引相手の名前、IBAN、および支払目的が明細ごとに抽出されます。

逆方向の支払については、bank/payments/export を介して pain.001 形式でエクスポートされます。

Revolut Business CSV

Revolut Business口座の取引明細をCSV形式でダウンロードし、組み込みテンプレートである Revolut Business（templateId: "builtin-revolut"）を使用してインポートします。すべての会社でこのテンプレートが事前作成不要で利用可能です。bank/import-templates/list-builtin で一覧表示され、bank/import-templates/get で取得できますが、bank/import-templates/update および bank/import-templates/delete は HTTP 400 で拒否されます。アプリ内では銀行 (Bank) → インポートテンプレート (Import templates) の最上部に表示され、開くと設定を確認できます。保存を行うと、変更可能な独自の会社用テンプレートが作成されます。

POST /v1/bank/statements/import
{
  "bankAccountId": "…",
  "templateId": "builtin-revolut",
  "content": "Date started (UTC),Date completed (UTC),ID,Type,State,…"
}

State が COMPLETED の行のみがインポートされます。その他の行（PENDING など）は除外され、warnings にカウントされます。これらは、該当取引が完了した後のファイルによる後続のインポートで取り込まれます。
各行は、Date completed (UTC) の日付、Total amount の金額、Payment currency の通貨、ID を externalId、Description を説明文とする銀行取引になります。
出金の取引相手は Beneficiary name および Beneficiary IBAN となり、受取人のいないカード支払いの場合は Description 内の加盟店となります。入金の取引相手は Sender name および Sender account となります。
行は口座および通貨ごとにグループ化されます。International account number は銀行口座のIBANと一致している必要があり、銀行口座の通貨と一致する行のみがインポートされます。
インポーターは各行について、前行の残高に Total amount を加算した金額が Balance と一致するかを検証し、一致しない行を warnings にリストします。
ファイルには、Date completed (UTC)、ID、Type、State、Description、Payment currency、Total amount、Reference、Sender name、Beneficiary name の各列が含まれている必要があります。

インポートの際、組み込みテンプレートは以下の処理を行います：

前述の不明な取引先の自動作成の記載に従い、未登録の入金送信者ごとに顧客を、未登録の出金受取人またはカード加盟店ごとに仕入先を作成します。
前述の参照番号による請求書の紐付けのチェックに従い、Reference または Description に売上または仕入請求書の番号が含まれる行を照合し、支払を計上します。

請求書と一致しなかった行について、その Type に応じた計上ルールの勘定科目に計上します：

`Type`	計上ルール	デフォルト勘定科目	ルーマニア勘定科目	計上方法
`FEE`	`bank.fees`	6800	627	ルールの勘定科目を借方、銀行口座の元帳勘定を貸方。取引先：銀行口座名にちなんだ名前の仕入先
`CARD_PAYMENT`	`bank.cardPayments`	6209	628	ルールの勘定科目を借方、銀行口座の元帳勘定を貸方（VATなし）
`TOPUP`	`bank.topUps`	3010	1012	銀行口座の元帳勘定を借方、ルールの勘定科目を貸方

TRANSFER などのその他のタイプの行は、手動消込のために new ステータスのまま残ります。

勘定科目の変更は ledger/posting-rules/update で行います。組み込みテンプレートは次回のインポートから新しい勘定科目を使用します。計上ルールを無効にすることはできません。カード払いやトップアップを計上せずにインポートしたい場合は、Type=CARD_PAYMENT や Type=TOPUP の行を含まない revolutタイプの会社用テンプレートを作成し、それを使用してインポートしてください。このようにして計上されたカード払いは、後から仕入先請求書が登録された際にその請求書と自動で消込されません。両方を計上するのではなく、どちらか一方のみを計上してください。

revolutタイプの会社用テンプレートも同じ列を使用し、Type=FEE、Type=CARD_PAYMENT、Type=TRANSFER、Type=TOPUP のルール行を使用してタイプごとに仕訳を計上できます。テンプレートを指定せずに "format": "revolut-csv" でインポートした場合は、これらの処理を行わずに単に行のみがインポートされます。

Stripe CSV

Stripeダッシュボードからのエクスポートデータ（どちらのレポートでも利用可能です）：

レポート (Reports) → 残高 (Balance) → アクティビティごとの項目別残高変動 (Itemized balance change from activity)（推奨）：列 balance_transaction_id, created_utc, currency, gross, fee, net, reporting_category, description。
決済 (Payments) → エクスポート (Export)：列 id, Created (UTC), Amount, Fee, Currency, Description, Customer Description。

POST /v1/bank/statements/import
{
  "bankAccountId": "…",
  "format": "stripe-csv",
  "content": "balance_transaction_id,created_utc,currency,gross,fee,net,…"
}

Stripe専用の銀行口座を作成してください（例：名前を「Stripe」、GL勘定を2710または独自のサブ口座とする）。Stripeの残高は銀行口座のように機能します。チャージが流入し、手数料が差し引かれ、ペイアウト（出金）によって実際の銀行口座へ資金が移動します。

インポートの挙動：

各バランス取引（balance transaction）は、**総額（gross）**の金額で1件の銀行取引になります（externalId = balance transaction id）。
0ではない**手数料（fee）**は、逆符号の2件目の取引として作成されます（externalId = <id>:fee、取引相手「Stripe」）。これにより、手数料を売上とは別に費用として消込・計上できます。返金に伴い発生した手数料は正の金額として取り込まれます。
**ペイアウト（Payout）**行は、単一の負の金額の取引としてインポートされます。実際の銀行口座明細上の対応する入金取引と消込を行ってください。
金額が0の行はスキップされます。日付は created_utc（UTC）から取得されます。
資金移動を伴わない決済エクスポート行はスキップされます：Captured = false（承認/売上確定待ち）および Status が Failed/Canceled のもの。
0ではない**返金金額（Amount Refunded）**は、Refunded date (UTC) を日付とする3件目の負の金額の取引（externalId = <id>:refund）として作成されます。これにより、決済行に埋め込まれた部分返金や全額返金が失われません。

PSP決済消込（Stripe ペイアウトレポート）

一括払いのペイアウトを、その内訳となる注文、返金、手数料、チャージバックに分割するには、通常の明細インポートの代わりに決済消込（settlement）エンドポイントを使用します。2種類のStripeエクスポート形式に対応しています（自動検出されます）：

レポート (Reports) → ペイアウト (Payouts) → ペイアウト消込、項目別 (Payout reconciliation, itemized)（レポートタイプ payout_reconciliation.itemized.* または payout_reconciliation.by_id.itemized.*）：正確であり、バランス取引ごとに1行となります。本番環境（live）で推奨されます。
決済 (Payments) → エクスポート (unified payments)：チャージ単位のエクスポートです。ペイアウト消込が利用できないテスト/サンドボックスモードで機能します。売上確定済みのチャージは Transfer 列のペイアウトIDでグループ化され、未確定/失敗行はスキップされます（skippedNotSettled）。0ではない Amount Refunded は、チャージのペイアウトバッチ内の合成返金行となります（返金が実際には後続のペイアウトで清算されている可能性があるため近似値となります）。マッチング参照は、チャージID、PaymentIntent ID、Invoice Number、Client Reference ID、およびすべての … (metadata) 列（メタデータ内の注文番号など）から取得されます。

1つのCSVファイルに複数のペイアウトを含めることができます。Stripeは項目別レポートをセクションごとに1ファイル（…_charge_…、…_refund_…、…_fee_…）としてダウンロードします。これらすべてをインポートしてください。すでにインポートされているペイアウトの行は、まだ計上されていない限り、既存のバッチに統合され（updated カウンターに報告されます）、バッチの合計値が再計算されます。

POST /v1/bank/settlements/import
{
  "bankAccountId": "…",
  "provider": "stripe",
  "content": "balance_transaction_id,created_utc,…,reporting_category,…,automatic_payout_id,…"
}

インポートの挙動：

行は automatic_payout_id ごとに**決済バッチ（settlement batches）**にグループ化されます（ペイアウトごとに1バッチで、総額/手数料/純額の合計を持ちます。行の net の合計 = 実際の銀行口座に入金される金額）。ペイアウトの再インポートはスキップされます（skipped カウンター）。まだペイアウトに割り当てられていない行や、ペイアウト行自体はスキップされ、個別にカウントされます。
すべてのチャージ/返金/紛争の行は、以下の順序で売上請求書に自動消込されます：Eコマース注文の externalRef（order_id、payment_intent_id、source_id、charge_id、または任意の *_metadata[...] 列のいずれかの値）、これらの列に出現する請求書の fullNumber、および返金やチャージバックの場合は以前に消込されたチャージの charge_id（同一ファイルまたは過去のインポート）。
確認には bank/settlements/list / bank/settlements/get を使用し、残余の未処理分は bank/settlements/match { lineId, invoiceId }（または未消込に戻すための invoiceId: null）で修正します。

POST /v1/bank/settlements/post { id, date?, commissionPercent? } は、バッチ全体を1件のバランスの取れた仕訳として計上し、一致する請求書を消込します（paidAmount/paymentStatus、sale_invoice.paid Webhook）：

純額のペイアウトについて銀行口座のGLを借方計上し、差し引かれた手数料および手数料行についてPSP手数料（settlements.fees、デフォルト6800）を借方計上します。
一致するチャージについて売掛金を貸方計上します。返金およびチャージバックはこれを逆仕訳します。適用額は各請求書の残高を上限とし、超過分は警告とともに仮受金勘定（suspense account）に計上されます。
未消込のチャージ：commissionPercent が設定されている場合、手数料収益（settlements.commissionRevenue、デフォルト5001）と売手債務（seller liability）（settlements.sellerPayable、デフォルト4499）に分割されます（収集した資金の大半が売手に帰属するマーケットプレイスモデル）。設定されていない場合は、settlements.suspense（デフォルト4440、受入前受金）にプールされます。
platform_earning 行（Stripe Connectプラットフォーム手数料）は手数料収益に計上され、transfer 行（接続された売手へのペイアウト）は売手債務を減額します。
4つの勘定科目すべて、計上ルール（ledger/posting-rules）を介して会社ごとに上書き可能です。
チャージ、手数料、または返金がすでにStripe決済のエクスポート（bank/statements/import）を通じて別の銀行口座にインポートされている明細は、手数料、売掛金、または仮受金勘定には計上されません。代わりに、その net がその銀行口座の元帳勘定に貸方計上されるため、Stripe銀行口座のペイアウトがクリアされます。summary.clearedAmount はこの方法で移動した総額です。口座が保持している金額と異なる金額を持つ行は warnings に記載されます。計上すべき項目が残っていない場合、バッチは journalTransactionId を null として計上されます。

bank/settlements/list および /get は、バッチごとに clearedNet、clearingDifference（ペイアウト行から別の銀行口座が保持する金額を引いたもの。一致している場合はゼロ）、および clearingOpenCount（差異または未計上の移動がある行数）を返します。/get は行ごとに同様の情報を clearingBankAccountId、clearingBooked、clearingDifference、clearingUnposted として返します。1つのチャージの複数の返金行はまとめて比較されます。これは決済エクスポートには返金合計のみが保持されているためです。ペイアウトが計上された後にインポートされたStripe決済のエクスポートは、そのペイアウトの移動をスキップし、warnings にその名前を記載します。

手数料自体のVATは個別に請求されます（売手に対して手数料請求書を発行してください）。分割処理は収集された現金の配分のみを行います。

異なる通貨でのペイアウト

仕訳は常に会社の基準通貨で作成されますが、異なる通貨でのペイアウトも手動入力なしで自動的に計上されます：

バッチは計上日のレート（date、指定がない場合はペイアウト日、さらに指定がない場合は当日）で換算されます。為替レートは、公式レートと同等以上に新しい場合は会社自身のその通貨の為替レート（reference/exchange-rates/set）を使用し、そうでない場合はその日以前の最新の公式レートを使用します。該当日のレートが存在しない場合、呼び出しは 422 で失敗し、reference/exchange-rates/sync の実行を促します。
すべての勘定科目はそのバッチレートで換算されますが、**売掛金（accounts receivable）**のみ、各請求書が発行された時点の fxRate で消し込まれます。2つのレート間の差額は実現為替差損益として bank.fxGain（デフォルト5803）または bank.fxLoss（デフォルト6803）に計上され、仕訳の貸借一致が維持されます。
レスポンスの summary は使用された fxRate とその結果の exchangeDifference を返し、バッチは計上されたレートを保持します。自通貨がバッチ通貨と異なる一致した請求書は消込されません。その金額は警告とともに仮受金勘定に送られます。
1つのインポート制限として、複数の通貨が混在する単一のペイアウトは 422 で拒否されます。また、すでに保存されているバッチの通貨と異なる通貨での再インポートも拒否されます。

手動 / カスタムフィード

その他のデータは、プレーンなJSONとして送信することができます：

POST /v1/bank/transactions/import
{
  "bankAccountId": "…",
  "transactions": [
    { "date": "2026-07-01", "amount": "-25.00", "currency": "EUR",
      "counterpartyName": "…", "description": "…", "externalId": "unique-ref-1" }
  ]
}

再インポートの冪等性（idempotency）を維持するために、取引ごとに安定した externalId を提供してください。