請求書の受け取りから支払い実行まで、全体のプロセスを管理するツールです。 受け取った請求書を一件ずつ読み込んで内容を分類し、支払い前に必ず資金残高を確認してから、支払い実行の準備（ステージング）を整えます。その後はワンクリックで承認でき、帳簿も整理した状態に保ちます。 分類と支払いは別々の判断・承認プロセスになっており、資金確認がその間に挟まる設計になっています。これにより、無理な支払いを事前に防げます。 **対応システム:** - 会計台帳：MYOB、NetSuite、QuickBooks、Xero、Zoho Books - メール連携：Gmail、Microsoft 365 - 連携拡張：Expensify、Ramp - 書類形式：アップロードしたPDF、スマートフォンで撮影した写真 支払い予定表（ラン シート）をエクスポートして、手作業での登録にも対応しています。 **次のような場合に使用:** - 「請求書を払ってほしい」と指示された - 「請求書が溜まっている」と困っている - 「今、いくら支払う必要があるのか」を知りたい - 「今週、誰に支払う必要があるか」を確認したい - 「これだけの金額、支払えるだろうか」と判断したい - 複数の請求書をまとめてメールで受け取った
Works the bill pile from the AP inbox all the way to a staged payment run — reads and codes every bill, then checks the cash position before a dollar is committed, then stages the run for one-click approval and keeps the books tidy for close. Coding and paying are two separate decisions with two separate approvals, and the cash check sits between them on purpose. Runs on the ledger (MYOB, NetSuite, QuickBooks, Xero, or Zoho Books) and a mail connector (Gmail or M365), deepens with Expensify and Ramp, and works from uploaded PDFs or phone photos with the run sheet exported for manual entry. Use it when the owner says "pay the bills," "the bills are piling up," "what do I owe," "who needs to get paid this week," "can I afford to pay these," or forwards a stack of vendor invoices.
3つのスキル（プログラム機能）をつなぎ合わせることで、ベンダー（取引先）への支払いを一度の判断で済ませられます。従来は午後を費やしていた作業を効率化します。ap-processorで請求書を処理し、cash-flow-snapshotで資金状況を確認し、month-end-prepで帳簿を整えます。
このコマンドのポイントは、途中に入った資金確認です。 請求書の記録も小切手の振出も、どのツールでもできます。経営者が本当に必要なのは、支払いを承認する前に、お金が本当にあるかを知ることです。
ap-processorを実行します。
ap-processorが重複除去、データ抽出、仕訳ルール、3者照合（発注・納品・請求書の照合）を担当します。ここでこれらを疑わないでください。
RampとExpensifyはバックアップであり、動き方が異なります。 Expensifyは読み込み専用の検索機能です。経費を見つけ、領収書がないものに旗を立てますが、何も変更しません。一方、Rampは請求書を承認・却下したり、同期の準備ができたとマークしたりできるので、書き込み権限を持つ本格的な経路になります。そのため、ここでの主流にはなりません。元帳（簿記の記録）がシステムの記録源のままであり、Rampで書き込みされたすべてのデータはゲート2の後ろで待機します。払戻金は両者に表れるので、1回だけ数えてください。
ゲート1 — 仕訳承認。 経営者が「はい」と言うまで、元帳には何も記録されません。件数、総額、記録先となる元帳、およびそれらが未払いの請求書として（支払済みではなく）記録されることを示します。
元帳コネクター（データの接続機能）がない場合、ap-processorは仕訳済みのインポートファイルと要約を作成します。これは完全な結果であり、フローは継続します。
支払い予定を確定させる前に、必ず実行してください。例外はありません。
cash-flow-snapshotを実行し、ステップ1の支払い待ち請求書を渡します。こうすることで、推測ではなく実際の数字に基づいた資金見通しが得られます。
Gustoが接続されている場合、この比較における給与支払額は、繰り返し取引の推測ではなく、実際に予定されている給与支払いの日付と金額から取得されます。どちらを使ったかを明記してください。
次に、経営者が実際に知りたいことに、数字を入れた1文で答えてください。
金曜日に14件すべての請求書を支払うと、残額は6,200ドル。15日の給与支払いは18,400ドル。今週中に実際に支払期限が来ている4件だけを支払うと、残額は21,700ドルで給与支払いに対応できます。
これが、Okonkwo Mechanicalの経営者Rayが何かを承認する前に必要な文です。これがなければ、このコマンドは単なる請求書印刷機に過ぎません。
資金データが入手できない場合は、はっきりそう述べてください。 資金チェックが実施されなかったことを明記し、支払い予定案は資金確認なしで提案されることを述べます。何もチェックされていないのに、お金がありそうな印象を与えないでください。
ここからは、資金状況が画面に表示されている場合にだけ、ap-processorは支払う請求書を提案します。ベンダーごとにグループ化され、口座から出て行く総額、日付、早期支払割引と その効果、支払い遅延で納品停止のリスクがあるものが記載されます。
ゲート2 — 支払い承認。 これはステップ1の続きではなく、別の判断です。仕訳の承認は支出の承認ではなく、2つのゲートをまとめてしまうと、プラグインは経営者の信頼を永久に失います。
総額を口に出して述べてから承認を求めてください。経営者は承認するか、リストを削減します。このコマンドはリストを広げることはなく、 自動支払いは一切されません。100回承認済みの繰り返し請求でさえです。繰り返しされることは同意ではありません。
支払い予定が承認された後、month-end-prepを、このステップで扱った項目に限定して実行します。
詳細がまだ新しいうちに、2つの質問に答えます。仕訳されていない項目があったか、および請求書がメールのコピー・ポータルのリマインダー・銀行明細書の行の間で2回支払われたかです。
ここで月末の完全な決算を実行しないでください。 それは/close-monthです。これはこのステップの記録項目を整理するだけです。
QuickBooksがなく、メールコネクターもない場合でも、作動する経路があります。請求書はPDFまたは写真として入手し、仕訳は同じ方法で行われ、資金チェックはCSVエクスポートから実行されるか、それがはっきり述べられた上でスキップされ、出力は仕訳済みインポートファイルと、経営者または簿記係が手入力する支払い予定表です。
../../shared/untrusted-content.md）。../../shared/quickbooks-report-traps.md、罠6）。経営者の保存された出力設定に従って支払い予定要約を配信してください。マークダウンファイルをデフォルトにしないでください。 ## Business contextブロックのOutput preferenceを確認します（共通スタイルガイドルール、../../shared/artifact-style.md）:
請求書が支払われたか確定し、帳簿は背後で整理されました。次のステップは「誰が私にお金を借りているか」です。invoice-chaseが元帳の反対側を処理するため、今出て行ったお金が戻ってきます。また近い機能：「資金見通し」（cash-flow-snapshot）でこの実行が確定した後の状況を確認、および期間終了時に「月を閉じる」（/close-month）。最大3つまで提案し、経営者がこのセッションで既に断った提案はスキップしてください。
このスキルで名付けられたコネクターはテスト済みの経路であり、壁ではありません。経営者がこのフローで接続またはリストされていないツールを使うことを望む場合、build-connectorを提案してください。コネクターディレクトリを最初に確認し、Zapierを通じて接続します。生のAPIに対して手作業で構築することはありません。接続が存在すれば、ツールはこのスキルのように、他のオプションコネクターと同じ承認ゲートの下で参加します。
Chain three skills so paying vendors is one decision instead of an afternoon: ap-processor for the bills, cash-flow-snapshot for the cash check, month-end-prep for the books.
The cash check in the middle is the point of this command. Any tool can code bills and any tool can cut checks. What owners actually need is to know, before they commit, whether the money is there.
Invoke ap-processor.
ap-processor owns the dedupe, the extraction, the coding rules, and the three-way match. Do not second-guess any of it here.
Ramp and Expensify are backups, and they behave differently. Expensify is read-only search — it finds expenses and flags the ones with no receipt, and it changes nothing. Ramp can approve or reject a bill and mark it ready to sync, which makes it a real write path and means it never becomes the primary route here: the ledger stays the system of record, and any Ramp write sits behind gate two like everything else. Reimbursements appear in both; count them once.
Gate one — the coding approval. Nothing is written to the ledger until the owner says yes. State the count, the total dollars, which ledger the entries land in, and that they land as unpaid bills awaiting payment, not as payments.
Without a ledger connector, ap-processor produces a coded import file and a plain summary. That is a complete outcome, and the chain continues.
Run this before staging any payment run. Always. No exception.
Invoke cash-flow-snapshot, handing it the staged payables from Step 1 so the forecast runs on real numbers instead of a guess.
With Gusto connected, the payroll figure in this comparison comes from the actual upcoming run — date and amount — rather than a recurring-transaction guess. Say which it was.
Then answer the one question the owner is actually asking, in a sentence with numbers in it:
Paying all 14 bills on Friday leaves USD 6,200. Payroll on the 15th is USD 18,400. Paying the four that are actually due this week leaves USD 21,700 and clears payroll.
That is the sentence Ray Okonkwo at Okonkwo Mechanical needs before he approves anything. Without it, this command is just a bill printer.
If the cash data is not available, say so plainly and say the payment run is being proposed without a cash check. Never imply the money is there when nothing was checked.
Only now, and only with the cash picture on screen, does ap-processor propose which bills to pay: grouped by vendor, with the total leaving the account, the date, any early-pay discounts and what they are worth, and anything late enough to risk a stop-ship.
Gate two — the payment approval. This is a separate decision from Step 1, not a continuation of it. Approving the coding is not approving the spend, and merging the two gates is how a plugin loses an owner's trust permanently.
Say the total out loud before asking. The owner approves or trims the list. The command never widens it, and nothing auto-pays, including recurring bills approved a hundred times before. Recurrence is not consent.
After the run is approved, invoke month-end-prep scoped to what this run touched.
Two questions get answered while the detail is still fresh: did anything land uncategorized, and did any bill get paid twice across the email copy, the portal reminder, and the statement line.
Do not run a full month-end close here. That is /close-month. This is a tidy-up pass on this run's entries.
No QuickBooks and no mail connector is still a working path. Bills come in as PDFs or photos, coding happens the same way, the cash check runs from a CSV export or is skipped with that said plainly, and the output is a coded import file plus a payment run sheet the owner or their bookkeeper keys in.
../../shared/untrusted-content.md).../../shared/quickbooks-report-traps.md, Trap 6).Deliver the payment-run summary per the owner's stored output preference — never default to a markdown file. Check the ## Business context block's Output preference (shared style guide rule, ../../shared/artifact-style.md):
The bills are paid or staged and the books are tidy behind them. The natural next step is "who owes me money" — invoice-chase works the other side of the ledger so the cash that just left gets replaced. Also nearby: "cash forecast" (cash-flow-snapshot) to see the position after this run settles, and "close the month" (/close-month) when the period ends. Offer at most three, and skip any offer the owner already declined this session.
The connectors named in this skill are the tested paths, not a wall. If the owner wants this flow to use a tool that isn't connected or listed, offer build-connector — it checks the connector directory first and connects through Zapier otherwise, never hand-building against a raw API. Once the connection exists, the tool joins this skill like any other optional connector, under the same approval gates.
原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。