ペイアウト残高と準備金の表示が もっと分かりやすくなる

図解 ： Shopify Payments のペイアウト残高と準備金表示が分かりやすくなる Shopify Payments / 表記改善 ペイアウト残高と準備金の表示が もっと分かりやすくなる 「To be paid（支払い予定）」が「Payout balance（ペイアウト残高）」に。算出ロジックの説明テキストも追加。タイミングや金額、準備金の条件には一切変更なし、純粋な表記改善のみ。 このページの構成 30秒で要点 Before / After ： 画面で見る変化 ペイアウト残高はどう計算されるのか 準備金（Reserve）とは何か 変わるもの／変わらないもの 技術者が押さえるべき5つのポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 30秒で要点 Shopify Payments の Payouts ページ （支払い管理画面）で、これまで「To be paid」と表示されていた金額の名称が「 Payout balance（ペイアウト残高） 」に変更。 あわせて、その金額が「 売上 − 返金 − チャージバック異議 − 手数料 」で計算されることを説明するヘルプテキストが追加された。準備金がある場合の説明文も追加。 金額・タイミング・準備金の条件は一切変わらない。 純粋に「読みやすさ」だけの改善。 名称統一 「To be paid」→「Payout balance」へ。Finance（財務系画面）で使われている用語に揃えられた。 計算式を明文化 「payments − refunds − disputes − fees」と算出ロジックが画面上のヘルプで読めるようになった。 準備金の説明も追加 準備金がある場合、別枠で金額が表示され「異議・返金・チャージバック・リスクをカバーするため一時的に保持している」と明示される。 2 Before / After ： 画面で見る変化 BEFORE To be paid $ 12,450 （金額の算出ロジックの説明は画面上に無し） In reserve $ 2,300 （準備金の目的の説明は画面上に無し） AFTER Payout balance $ 12,450 payments − refunds − disputes − fees で計算されます In reserve $ 2,300 異議・返金・チャージバックのリスクをカバーするため一時的に保持されています 本文は「Payouts ページ上のラベル・ヘルプテキストのみ」が更新対象であることを明言。金額・タイミング・準備金の条件には変更なし。 3 ペイアウト残高はどう計算されるのか この式自体は 従来からあったロジックの明文化 。「画面で見える金額はどう作られているのか」が初見の運用担当者にも一目で分かるようになった。 4 準備金（Reserve）とは何か 一時的に保持される資金 アカウントに準備金が設定されている場合、Payouts ページに準備金の額が 別枠で 表示される。 カバー対象 異議申し立て（disputes）、返金（refunds）、チャージバックのリスク。これらが発生した場合の支払いに備えて確保される。 準備金の 条件・期間・解除タイミングについては本記事内に記載なし 。詳細は Shopify ヘルプセンターの該当ページを参照する必要がある。 5 変わるもの／変わらないもの 項目 変更 内容 「To be paid」のラベル 変更 →「Payout balance」（Finance 用語に統一） 計算式の説明テキスト 追加 payments − refunds − disputes − fees が画面で読める 準備金の表示 説明追加 金額は従来通り別枠表示。「なぜ保持されているか」のヘルプテキストが付いた ペイアウトのタイミング 変更なし 支払サイクルは従来通り ペイアウト金額 変更なし 計算ロジック自体は不変 準備金の条件 変更なし 準備金率や解除条件は不変 6 技術者が押さえるべき5つのポイント 1. UI 層のみの変更 変わるのは Payouts ページのラベルとヘルプテキストだけ。 算出ロジック・支払い動作・金額そのものには触っていない 。バックエンド処理は不変。 2. API 仕様の変更は言及無し Admin API／Payments API のフィールド名が変わるかどうかは本文に記載なし。 「画面ラベルだけ」と読むのが安全 。連携実装側で `to_be_paid` 等の名前に依存している場合は念のため確認推奨。 3. Finance 用語に揃えた 「matching the language used across Finance」と本文で言及。複数の財務系画面の用語ばらつきを揃える整備の一環と読める。経理担当が複数画面を行き来する案件で説明工数が下がる。 4. 準備金は依然「別枠」 準備金は Payout balance に 含まれない 別表示。「振り込まれない金額」が画面上で識別しやすくなったので、入金見込みのズレが起きにくい。 5. ヘルプテキストが「現場の問い合わせ」を減らす 「なぜこの金額？」「なぜ全部入金されない？」というオーナー／経理からの定番質問が画面上で自己解決しやすくなる。 運用ドキュメントや FAQ のうち、この 2 トピックを薄く差し替えるだけで保守工数を圧縮できる 余地がある。 7 業務に活かせる3つのユースケース USE CASE 1 運用ドキュメント／オーナー向け FAQ の差し替えで保守工数を削減 課題 「『To be paid』って何ですか？」「入金額が請求書と合わない」という問い合わせがクライアント側で発生し、運用 SE が都度説明している。 打ち手 運用マニュアル／クライアント FAQ の該当箇所を「Payout balance ＝ payments − refunds − disputes − fees」「準備金 ＝ disputes/refunds/chargeback 用に一時保持」に置き換える。スクショ差し替えのみで内容は変えずに反映可能。 効果 問い合わせ件数の削減＋クライアント側の経理担当の自走化。月次レポート読み合わせの時短。 技術メモ UI のみの改定なので、運用手順書のスクショと用語表だけを置換すれば良い。API ・ ETL 側コードは触らない。 USE CASE 2 会計連携／月次締めの用語マッピング表を「Payout balance」に統一 課題 Shopify 側の入金見込みと会計ソフト側の売掛回収を突合するときに、「To be paid」「振込予定額」「入金予定額」など呼称がぶれていて担当者が混乱する。 打ち手 社内・クライアント側のマッピング表（Shopify 用語 ↔ 会計勘定）を「Payout balance」「In reserve」に統一。Shopify 公式が Finance 系画面で揃えてきた流れに乗る。 効果 月次締め時のミスコミュ削減、自動化スクリプトのカラム名整備にも繋げやすい。 技術メモ 本記事内では API フィールド名変更の言及はないので、ETL の取り込みキーは現状維持のまま、 表示用ラベルだけ揃える のが現実的。 USE CASE 3 キャッシュフロー予測 ／ 準備金影響のクライアント説明資料を更新 課題 準備金が積まれているクライアントから「いつ全額入ってくるのか」「何が引かれているのか」の確認が定期的に来る。説明に毎回時間がかかる。 打ち手 クライアント向け月次レポートのキャッシュフロー予測パートで、「Payout balance（=今回振り込み）」と「In reserve（=保留中）」の2軸スクショ＋ヘルプテキスト引用に統一。準備金の目的説明はShopify画面そのものを引用して根拠付ける。 効果 「Shopify 公式の文言」として説明できるので説得力が増し、合意形成が早くなる。 技術メモ 準備金の条件・解除タイミングは本記事内に記載なし。Shopify ヘルプセンターの該当ページを別ソースとして添付するのが安全。 8 提案で使える1行サマリ 「Shopify Payments の Payouts 画面で 『To be paid』が『Payout balance』に改名 、計算式（payments − refunds − disputes − fees）と 準備金の目的説明 が画面で読めるようになった改定。 金額・支払いタイミング・準備金条件は一切不変 のラベルのみ更新なので、影響範囲はマニュアル／FAQ の用語差し替えに限定できる。」 source ： changelog.shopify.com / clearer-payout-balance-and-reserve-information-in-shopify-payments