payroll-prep

給与計算の準備

給与を支払う前に、労働時間を正確に把握しましょう。

給与計算は、最もミスの許されない財務ワークフローです。請求書に誤りがあれば翌週に修正できます。しかし、給与を間違えると、家賃を払えなくなる人が出て、オーナーが従業員を失う最も早い原因になります。このスキルはすべて、この非対称性を前提に設計されています。機械が情報をまとめて確認し、オーナーが判断します。

ステップ 1 — 何よりも先に対象期間を確定する

給与期間の開始日と終了日、支払日、今回の対象者を確認します。期間を間違えると、誰かの給与が1週間分重複したり、抜けたりします。期間が月末をまたぐ場合は、思いのほか簡単に起こるミスです。

従業員名簿も確認します。期間の途中で勤務を開始した新入社員、退職者、休職中の人を確認してください。reference/timesheet_intake.mdを参照してください。

ステップ 2 — タイムシートを取得する

Gusto に接続している場合、何かを作成する前に、まず Gusto 自身に作業を妨げる要因を確認します。Gusto の給与計算ブロッカー確認（list_payroll_blockers）を呼び出してください。ブロッカーが返された場合は、それぞれの意味、対応する人、対応場所を平易な言葉で説明します。たとえば、「小切手での支払いは未対応」とは、この会社が紙の小切手で支払っており、連携機能では準備できないため、オーナーがその部分を Gusto で直接処理することを意味します。「Plaid 経由で銀行口座が接続されていない」とは、オーナーが Gusto の設定で銀行口座を接続する必要があることを意味します。「時給制従業員は未対応」は、今回の給与計算が月給制の従業員のみであっても、アカウントレベルでブロックされることがあります。ブロッカーは処理の振り分けに使う情報であり、失敗を意味するものではありません。ここでは引き続き今回の給与計算を作成して検証し、ブロッカーの一覧を添えた実行シートを納品物とします。

次に、期間に関する入力情報を、それぞれ別のツールから取得します。**労働時間：**給与期間を指定してlist_time_recordsを呼び出します。何よりも先に、そのsourceフィールドを確認してください。nativeは、出勤時刻、退勤時刻、休憩時間を含むシフトを返します。third_partyは、会社の勤怠管理パートナーからのタイムシートを返します。個々のタイムシートの日ごとの明細を取得するにはget_time_sheetを使います（このツールはネイティブのシフト ID を受け付けません）。noneは、Gusto にこの会社の労働時間データがないことを意味するため、下記のスプレッドシート経由の方法で補います。**休暇：**期間を指定してstatus: approvedのlist_time_off_requestsを呼び出します。承認済みの休暇日はすべて PTO または病気休暇として有給扱いにし、勤務時間として扱ってはいけません。保留中の申請は注意を示すものであり、有給日ではありません。残高：get_time_off_balancesを呼び出します。ステップ 4 の「利用可能残高を超える PTO」の確認では、この情報を参照します。賃金と分類：list_employeesで取得した各人の報酬情報を含む従業員名簿を使います。賃金は Gusto から取得し、タイムシートから取得してはいけません。これらの呼び出し形式は../../shared/connector-call-shapes.mdに記載されています。

**オーナーが補える打刻漏れ。**ステップ 4 で退勤時刻のないシフトが指摘され、オーナーが実際の時刻を伝えた場合は、record_timeで記録します。記録するのは、オーナーが明示した時刻だけです。記録前にオーナーに提示し、2件目の記録を追加するのではなく、既存のシフトをupdateします。必須で、欠けていると処理が拒否されるパラメーター（タイムゾーン、Gusto 独自の勤怠管理におけるジョブ、シフトとして扱う ID）と、再読み込み時の注意点（確認済みの勤務時間を持つ請負業者は、打刻時刻が空欄の状態で返されます。再度書き込んではいけません）については、../../shared/connector-call-shapes.mdのrecord_timeの行を参照してください。呼び出し前にその行を読んでください。このスキルで打刻を変更する方法はこれだけです。推測した時刻を記録することは決してありません。

**その後、何かを準備する前に、データソースからデータが返ってくることを確認します。**従業員名簿（list_employees）と給与スケジュール（list_pay_schedules）を取得します。会社の従業員数が報告されているにもかかわらず、どちらかのリストが空で返される場合、またはブロッカー確認が回答を返さずエラーになる場合は、給与データソースには接続できているものの、データが提供されていません。準備の処理を中止し、「Gusto には接続できていますが、従業員または給与スケジュールが返されなかったため、これを使って給与計算を準備できません」と一文で伝え、下記のスプレッドシート経由の方法を案内してください。従業員名簿が空の状態で給与計算を作成してはいけません。接続バッジが緑色であることを、データが存在する証拠として扱ってはいけません。 QuickBooks Payrollが接続されている場合は、同じ項目をそこから取得します。ここでは、よく似て見える2種類の失敗があり、事業主はそれぞれを異なるものとして受け止めます。データソースが空（従業員数を報告している会社なのに、Gustoのリストが行なしで返る）のはデータの欠落です。その旨を伝え、ランシートを使います。データソースに矛盾がある場合はツールの不具合です。同じ会社について、qbo_payroll_get_company_payroll_readinessがhas_employees: falseとrun_payroll_ready: falseを返す一方で、qbo_payroll_get_employeesがtotal_countとして50を返すことは、どちらも真であるはずがありません。これは会社が保有するデータ量には関係ありません。この場合は、従業員リストを名簿として使います（行が返された呼び出しだからです）。準備状況が未準備を示している間は給与計算を開始せず、矛盾が「未準備」の陰に隠れず記録に残るよう、両方の数値を1行で事業主に伝えます。そのうえで、以下のスプレッドシートの手順に進み、その名簿を使います。事業主がQuickBooks Payrollに入力する、検証済みのランシートを作成するのが成果物です。これはデータソースが空の場合と同じです。これは第一級のデータソースであり、フォールバックではありません。従業員の完全な名簿（給与形態、給与レートと頻度、雇用状況、PTOポリシーの残高を含む）、給与スケジュールとその頻度、さらに従業員ごとの総支給額、労働時間、税金の内訳を含む直近の完了済み給与計算が取得できます。労働時間の情報源がタイムシートの場合は、その旨が記録に示されます。これは、ステップ4の異常チェックに必要な情報です。

このデータソース固有の注意点が2つあります。従業員にはアクティブフラグとは別に雇用状況が設定されるため、アクティブと表示されていても、給与対象外または有給休暇中の場合があります。給与計算に含める前に、両方を確認してください。また、1人の従業員に12件以上の給与レートが設定され、その大半の労働時間がゼロであることもあります。そのため、最初に表示されたレートではなく、実際に労働時間が記録されているレートを使って合計してください。

どちらも利用できない場合は、アップロードされたスプレッドシートまたはCSVを使います。これは完全にサポートされている方法です。事業主が給与計算サービスに入力する、検証済みのランシートを作成すれば、十分な成果となります。小規模なチームの多くは今も週末に撮影した紙のタイムシートを使っていますが、それでも問題ありません。

1人につき1日1行にまとめます。日付、出勤時刻、退勤時刻、休憩時間、通常労働時間、時間外労働時間、PTO、および事業者が職務別に労働時間を管理している場合は職務または区分を記録します。

ステップ3 — 労働時間を合計する

個人ごと、チームごと、最後に給与計算全体の順に、通常労働時間、時間外労働時間、倍額割増時間、PTO、祝日、および無給時間を計算します。

時間外労働のルールは州や事業者の従業員区分によって異なり、誤ると給与が不足します。事業主が示したルールを使い、指定がない場合は一般的な週単位の時間外労働のデフォルトを適用し、どのルールを適用したかを伝えます。reference/anomaly_rules.mdには、週の途中での給与レート変更、複数の職務にまたがる日、深夜をまたぐシフトなど、計算上の注意点が記載されています。

打刻漏れがあっても、時刻を推測して埋めてはいけません。 出勤時刻があり退勤時刻がないシフトの労働時間は不明であり、不明な労働時間として報告します。

ステップ4 — すべての異常にフラグを立てる

これがこのスキルの中核です。reference/anomaly_rules.mdに記載されたチェックをすべて実行し、見つかった項目をすべて、該当する従業員名、日付、具体的に問題と思われる内容とともに提示します。

• 打刻漏れと退勤打刻のないシフト
• その人の通常のパターンを超える時間外労働時間。通常時と今回の両方の数値を記載します
• 通常勤務している従業員の労働時間がゼロ
• スケジュールで予定されていた時間を大幅に超える労働時間
• 前回の給与計算以降に変更された給与レート
• 重複または時間帯が重なる記録
• 利用可能残高を超えて取得されたPTO
• 前回の給与計算では支払対象だったのに、今回は含まれていない従業員
• 採用記録がないまま追加された新しい従業員

フラグは事業主に伝えます。黙って修正してはいけません。 打刻漏れへの正しい回答を知っているのは従業員と事業主だけです。その間にもっともらしい推測をすると、レポート上は正しく見える誤った給与支払いにつながります。

ステップ 5 — 承認前に給与計算の内容を提示する

給与計算シートを提示します。従業員ごとに、種別ごとの労働時間、総支給額、およびその従業員に該当するすべてのフラグを示します。続いて合計を示します。総労働時間、総支給額、利用可能な場合は雇用主負担の税金と拠出金、必要な現金の総額、支給日です。

前の期間と比較し、10％を超える変動があれば説明します。給与額が4,000米ドル増えたなら、その理由があります。オーナーが銀行残高を見て気づく前に、このスキルから説明を受けるべきです。

現金の情報が利用できる場合は、この給与計算を実行しても資金が足りるかを伝えます。利用できない場合は、問題ないかのようにほのめかさず、その旨をはっきり伝えます。

ステップ 6 — フラグを一つずつ解決する

各フラグについてオーナーに説明します。それぞれについて、何が見つかったのか、そのままにした場合にどうなるのか、どう対応したいのかを伝えます。回答を記録して反映します。

フラグをひとまとめにして「これでよさそうですか？」と尋ねてはいけません。一つひとつが、従業員の給与に関わるものです。

ステップ 7 — 承認ゲート

オーナーが給与計算を明示的に承認するまで、何もステージングしません。

質問する前に、人数、総労働時間、総支給額、口座から出ていく現金の総額、支給日、および未解決のままにすることを選んだフラグの数をはっきり伝えます。

それから尋ねます。このゲートを省略したいというオーナーには、誤った給与計算は直接入金が行われた後では取り消せないため、このゲートを設けていることを、一度だけ、説教じみた言い方をせずに伝えます。

Gusto が接続されている場合は、給与計算をステージングします。list_payrolls を processing_statuses: unprocessed でフィルタリングし、数週間先の end_date を指定して未処理の給与計算を探します（日付フィルターは給与期間に対するものであり、期間がまだ終了していないと、条件を指定しない呼び出しでは該当期間を見落とすことがあります）。次に、支給日が最も近いものを選び、get_payroll で読み取ってから、承認済みの労働時間、PTO、および該当するボーナス行を update_payroll で書き込みます。重要なのは次の 2 つの形式です。どちらも ../../shared/connector-call-shapes.md に記載されています。値は加算ではなく置き換えになるため、「Maria にあと 5 時間」は新しい合計を送信することを意味します。先に「40 → 45」とオーナーに示してください。また、従業員名簿がまだ作成されていない給与計算では、実際の更新の前に、空の update_payroll 呼び出しを 1 回実行して名簿を作成します。run_payroll は実行しません。Gusto でオーナーが押すボタンです。QuickBooks Payroll が接続されている場合、コネクターは読み取り（従業員名簿、給与レート、スケジュール、実行準備状況、前回の給与計算）のみを行い、給与計算のステージング書き込みは行わないため、オーナーが入力するのは検証済みの給与計算シートです。コネクターが現在対応しているのはこの方法であり、劣った方法ではありません。どちらのシステムでも、送信するのはオーナーです。どちらも接続されていない場合は、手動入力用の検証済み給与計算シートを作成します。ステップ 2 の Gusto のブロッカーによって接続経由でのステージングができない場合は、検証済み給与計算シートと、わかりやすく記載したブロッカー一覧を結果として提示します。失敗として扱わず、その旨を伝えます。

ステップ 8 — 会計帳簿に同期する

給与計算の送信後、仕訳を元帳に記帳します。総賃金、雇用主負担の税金、および案件に割り当てられる労務費を記録します。ロゴではなく、機能の有無を確認してください。台帳が接続されていても、コネクターに仕訳を書き込む手段がなければ記帳できないため、その旨を一行で伝え、貸借の一致した仕訳をオーナーまたは簿記担当者に渡して入力してもらいます。これは失敗ではなく、完了した結果です。提案した金額ではなく、実際に実行された金額と一致していることを確認します。オーナーが最後の手順で何かを編集した場合は、両者が異なるためです。

してはいけないこと

• チップ、賃率、または分類を推測しないでください。 不明な勤務時間は、従業員名と日付を添えて記載します。
• 異常値を黙って修正しないでください。 一見明らかなものでも同様です。オーナーが、あなたの知らない事情を把握している場合があります。
• 給与計算を実行しないでください。 準備まで行い、送信はオーナーが行います。このスキルから run_payroll を呼び出すことはありません。QuickBooks PayrollでもGustoでも同様です。給与システムに接続されていても、給与計算を実行してよいことにはなりません。
• update_payroll に差分を送らないでください。 値は置き換えられます。get_payroll から新しい合計を計算し、両方の数値を示して、合計を送信します。
• オーナーが申告していない打刻を記録しないでください。 record_time にはオーナーが提示した時刻のみを入力し、オーナーが入力内容を確認してから記録します。
• 勤務時間と照合せずに賃率を読み取らないでください。 QuickBooks Payrollでは、1人の従業員に複数の賃率が設定され、ほとんどの賃率の勤務時間がゼロになっている場合があります。
• フラグを要約に埋もれさせないでください。 それぞれのフラグを、該当する従業員に紐付けてください。
• フラグの確認をまとめて行わないでください。 問題ごとに、従業員1人ずつ判断してください。
• コネクタがないことを作業の妨げにしないでください。 スプレッドシートを受け取り、検証済みのランシートを出力する方法も、想定された手順です。
• 前期間との比較を省略しないでください。 説明のない大きな変動は、入手できる警告の中で最も有用です。
• 従業員がいると報告しながら、誰も返さない給与ソースからランを準備しないでください。 接続済みのバッジはデータではありません。ソースからデータが届いていないことを伝え、スプレッドシートの手順を使ってください。
• 従業員のSSN、生年月日、自宅住所、銀行口座番号、またはカード番号を、ランシート、チャット、描画されたページに記載しないでください。 GustoとQuickBooks Payrollのペイロードにはこれらの情報が含まれます。読み飛ばしてください（../../shared/personal-data.md）。

出力

検証済みのランシートは、オーナーが保存した出力設定に従って提出してください。デフォルトでMarkdownファイルにしてはいけません。 ## Business context ブロックの Output preference を確認してください（共有スタイルガイドのルール、../../shared/artifact-style.md）。

• ビジュアルアーティファクト（デフォルト）： ハウススタイルのHTMLページとしてランシートを表示します。人員数、総支給額、口座から出ていく現金は統計タイルで示し、従業員ごとに1行を割り当て、勤務時間と給与は表形式の数字で表示します。各従業員に紐付くフラグにはすべてピルを付けます。Gustoからブロッカーが報告された場合は、平易な言葉で説明する専用パネルを設けます。
• docx / md / notion / canva の設定： 同じ内容を指定形式で提出します。DOCXまたはMarkdownファイル、コネクタ経由で作成するNotionページ（保存先を指定し、上書きしない）、またはCanvaコネクタ経由で作成するCanva Doc（実行ごとに新しいデザインを作成し、日付を付けて命名します。表はリストに変換します）。NotionまたはCanvaに接続されていない場合は、ビジュアルアーティファクトに切り替え、その理由を伝えてください。
• このスキルに最適： ビジュアルアーティファクトを使います。オーナーが従業員ごとに承認するシートです。

実行後

ランの準備が整い、フラグが解決され、帳簿への仕訳が記帳されています。最初から現金が懸念事項だった場合、次の自然なステップは「給与を支払えるか」です。/plan-payroll は、次回のランに向けて予測と請求書の回収フォローを行います。関連する項目として、次の30日間に今回のランが与える影響を確認する「現金予測」（cash-flow-snapshot）や、四半期の予定納税または1099の期限が近づいている場合の「税金」（/tax-prep）もあります。提案は最大3つまでとし、このセッションですでにオーナーが断った提案は省略してください。

参考ファイル

• reference/timesheet_intake.md — Gustoからの取得、スプレッドシートのアップロード、従業員名簿と期間の設定
• reference/anomaly_rules.md — すべてのチェック項目、そのしきい値、表現方法
• reference/run_sheet_format.md — ランシートのレイアウトと合計欄
• reference/books_sync.md — 仕訳の構造とジョブコストの配賦
• reference/gotchas.md — 従業員の給与不足や、同一期間への二重支払いにつながるミス

一覧にないツールの使用

このスキルで名前を挙げているコネクターは、テスト済みの経路であり、制限ではありません。所有者が、このフローで接続されていない、または一覧にないツールを使いたい場合は、build-connector を案内してください。これはまずコネクターディレクトリを確認し、該当するものがなければ Zapier 経由で接続します。生の API に対して手作業で構築することは決してありません。接続が確立されると、そのツールはほかの任意のコネクターと同様に、同じ承認ゲートのもとでこのスキルに加わります。