月初の経営会議。
部門別の損益を開くと、人件費がすべて本社の部門に乗っている。
給与は国内のサービスで回っているのに、NetSuiteには月に1本の仕訳しか入っていないからです。
NetSuiteと人事・給与SaaSの連携とは、国内のサービスで計算した給与の結果を、人件費の仕訳としてNetSuiteに戻すことです。
給与の計算そのものは、国内の給与サービスに任せます。
NetSuiteの給与機能は、日本の給与計算に対応していないからです。
問題は、その後にあります。
計算した人件費をNetSuiteにどの細かさで戻すか。
ここを決めないと、部門や案件の採算に人件費が乗りません。
では、どの細かさを選べばよいのか。
答えは、製品の機能ではなく、経営会議で見たい損益の単位から出ます。
📌 この記事で分かること
- NetSuiteで日本の給与計算をしない理由（公式情報）
- 人件費をNetSuiteに戻す3つの粒度と、選び方
- 勤怠・給与・NetSuiteの月次の締めの順番
- SmartHR・freee人事労務・マネーフォワード クラウド給与・KING OF TIMEのつなぎ方
この記事の前提：人事・勤怠・給与は国内の専用サービスに置き、会計はNetSuiteで行う会社を想定しています。
人事の領域を製品の比較から外してよい理由は、NetSuiteとOdooの人事・勤怠・給与で扱いました。
NetSuiteで、日本の給与計算はしない
まず事実から。
NetSuiteの給与機能（SuitePeople U.S. Payroll）について、Oracleの公式ヘルプには次のように書かれています。
- 米国の連邦・州・地方の給与税にのみ対応する
- 複数の子会社を持つ場合も、給与計算できるのは米国の子会社だけ
（出典：Oracle NetSuite ヘルプ「SuitePeople U.S. Payroll」、2026年9月23日確認）
米国の給与機能の中身は、SuitePeople U.S. Payrollとはで解説しています。
米国以外の給与のための仕組みはある
Oracleは、米国以外の従業員の給与データを扱う「Paycheck Journal」という機能も用意しています。
ただし公式ヘルプでは、パートナーが外部の給与計算とつなぐための機能と説明されています。
パートナーの給与の仕組みを使わずに、利用者が直接使うことは想定されていません。
（出典：Oracle NetSuite ヘルプ「Paycheck Journal Feature」、2026年9月23日確認）
日本の会社にとって現実的な形は、次の2つの組み合わせです。
- 給与の計算・社会保険・年末調整は、国内の給与サービスで行う
- 計算した結果の人件費を、仕訳としてNetSuiteに戻す
年末調整とは、1年間の給与から納める所得税を、年末に正しい額へ精算する手続きです。
こうした日本固有の手続きに追いつき続けることが、国内サービスの価値の源泉です。
人件費を戻す3つの粒度
給与の結果をNetSuiteに戻すとき、決めるのは細かさ（粒度）です。
粒度は3段階あります。
| 粒度 | NetSuiteに入るもの | 見えるようになること | 準備が必要なもの |
|---|---|---|---|
| A. 会社合計 | 給与・社会保険料などの合計の仕訳 | 会社全体の人件費 | 科目の対応だけ |
| B. 部門別 | 部門ごとの人件費の仕訳 | 部門ごとの損益 | 従業員と部門の対応 |
| C. 案件・工程別 | 工数で案件や工程に配った人件費 | 案件・製品ごとの採算 | 部門の対応＋工数の記録 |
細かくするほど、AIに損益の変化を説明させたり、採算の悪い案件を人件費から洗い出させたりしやすくなります。
Aのままでは、部門にも案件にも分けられず、AIでも原因を追えません。
A．会社合計｜いちばん軽いが、採算は見えない
給与の総額と、社会保険料・税金などの預り金を、1本の仕訳で入れます。
決算には、これで足ります。
ただし、どの部門で人件費がかかっているかは、NetSuiteでは見えません。
向いている会社：部門が少なく、部門別の損益を見ていない会社。
B．部門別｜多くの会社の出発点
従業員ごとの所属部門で、人件費を部門に分けて入れます。
部門ごとの損益に、人件費が乗ります。
準備するのは、給与サービスの部門とNetSuiteの部門の対応です。
部門の名前やコードが両者でずれていると、毎月の取り込みで止まります。
向いている会社：部門別の損益で経営判断をしている会社。多くの会社がここから始めます。
C．案件・工程別｜採算を見たい会社
工数の記録を使い、人件費を案件や工程に配ります。
案件ごと、製品ごとの採算に人件費が乗ります。
ここで要るのは、勤怠ではなく工数です。
勤怠は「何時から何時まで働いたか」。
工数は「どの案件に何時間かけたか」の記録です。
工数の取り方は工数管理を「現場の作業」で終わらせない、配賦の考え方は原価の配賦の意味と重要性で扱っています。
向いている会社：受託開発・サービス業・個別受注の製造業など、案件ごとに採算を見る会社。
粒度の選び方
| いまの会社の状況 | おすすめの粒度 |
|---|---|
| 部門別の損益を見ていない | A. 会社合計 |
| 部門別の損益で判断している | B. 部門別 |
| 案件・製品ごとの採算を見たい。工数を記録している | C. 案件・工程別 |
| 案件の採算を見たいが、工数を記録していない | まずB。工数の記録を始めてからCへ |
冒頭の問いへの答えは、この表です。
見たい損益の単位が、そのまま粒度になります。
いきなりCから始める必要はありません。
工数の記録が定着する前にCを選ぶと、配る根拠の弱い数字ができあがります。
粒度は、あとから細かくできます。
個人の明細は、NetSuiteに入れない
どの粒度でも、共通のルールが1つあります。
給与の明細そのもの（誰がいくらもらったか）はNetSuiteに入れません。
会計に要るのは、部門や案件ごとの合計の金額です。
個人別の明細を入れると、誰が見てよいかの権限の設計が一気に重くなります。
Cの粒度でも、配るときに使うのは「部門ごとの人件費」と「工数」です。
個人の給与額を、案件に直接載せる必要はありません。
月次の締めの順番
勤怠・給与・NetSuiteの3つには、締める順番があります。
順番が決まっていないと、月次の締めで数字が合いません。
- 勤怠を締める（勤怠サービス）：その月の労働時間を確定する
- 給与を計算して確定する（給与サービス）：勤怠の結果を取り込み、給与を確定する
- 人件費の仕訳を取り込む（NetSuite）：選んだ粒度で仕訳を入れる
- 工数で配る（NetSuite・Cの場合）：案件や工程に人件費を配る
- 月次の損益を確かめる（NetSuite）
いちばん起きやすいのは、3の前に月次の損益を見てしまうことです。
人件費の入っていない損益を見て、判断を誤ります。
締めの日程表には、3の日付を必ず書き入れてください。
働いた月と、払う月がずれる会社
月末で締めて、翌月に払う会社は少なくありません。
この場合、人件費を「働いた月」と「払った月」のどちらの費用として入れるかを決めておきます。
これは会計の方針で、経理と顧問の税理士が決めることです。
つなぎの仕組みは、その方針に合わせて作ります。
先に決めておかないと、仕訳の日付で毎月迷います。
方針が決まれば、手順3で付ける日付も1つに決まります。
締めの順番を、担当者の名前で書く
5つの手順には、それぞれ別の担当者がいることが多いものです。
勤怠は人事、給与は労務、仕訳と損益は経理、というように分かれます。
手順ごとに担当者の名前と締切の日を書いた表を作り、毎月同じ表で回してください。
担当者が替わっても、この表を渡せば引き継ぎが済みます。
4つのサービスの、つなぎ方
主なサービスについて、公式情報で確かめたことを並べます。
4つとも公式サイトでNetSuiteとの連携の案内は確認できませんでした。
（2026年9月23日時点。日系SaaS全体の同じ事情はNetSuite×日系SaaS連携マップで扱っています）
4つのサービスとNetSuiteの間で、何が流れるかを図にすると、次のとおりです。
SmartHR｜従業員の情報をAPIで取り出せる
SmartHRは、開発者向けにAPIを公開しています。
- 従業員の情報、部署、役職などを扱える
- 認証は、アクセストークンとOAuthの両方に対応
- Webhook（出来事が起きたときに相手のシステムへ自動で知らせる仕組み）がある
- 開発用の検証環境（サンドボックス）がある
- APIを使えるかは、契約のプランによる
（出典：SmartHR API ドキュメント、2026年9月23日確認）
NetSuiteとの間では、従業員の情報（氏名・部門・入退社日）を渡す用途に向いています。
freee人事労務｜従業員と給与明細のAPIがある
フリー株式会社は、2019年4月15日に、freee人事労務のAPIの公開を発表しています。
公開されたのは、従業員の情報・給与明細・賞与明細の3つです。
給与明細のAPIから部門ごとの合計を作り、仕訳にする形が考えられます。
その場合も、個人の明細はNetSuiteに入れず、合計にしてから渡します（第3章）。
マネーフォワード クラウド給与｜公式の会計連携は同社の会計向け
マネーフォワード クラウド給与の機能一覧では、同社のクラウド会計などへの仕訳の自動作成が、会計連携として案内されています。
（出典：マネーフォワード クラウド給与「機能のご紹介」、2026年9月23日確認）
他社の会計ソフト向けの仕訳の出力は、公式の案内を確認できませんでした。
一方、給与の確定後に、支給・控除・勤怠の項目をCSVでダウンロードできると案内されています。
（出典：マネーフォワード クラウド給与サポート「給与計算の確定処理後にデータをダウンロードする方法」）
NetSuiteとの間では、このCSVから部門ごとの合計を作り、仕訳の形にして取り込む前提で設計します。
KING OF TIME｜勤怠のWeb APIを直接使える
KING OF TIMEのヘルプでは、連携サービスを通さずに、利用者がWeb APIを直接使えると案内されています。
- 全権管理者が、外部サービス連携の設定でWeb APIを有効にする
- 読み取り・書き込みの権限を指定して、アクセストークンを発行する
- 接続元のIPアドレスを制限できる
（出典：KING OF TIME FAQ、2026年9月23日確認）
勤怠の結果は、まず給与サービスに渡すのが基本です（第4章の手順1→2）。
NetSuiteに勤怠を直接入れるのは、休暇の残数などを持たせたい場合に限ります。
比較表
| サービス | 主な役割 | NetSuiteに渡すもの | つなぎ方の例 |
|---|---|---|---|
| SmartHR | 人事・労務 | 従業員の情報 | API＋Webhook |
| freee人事労務 | 人事・給与 | 従業員の情報／部門ごとの人件費 | API |
| マネーフォワード クラウド給与 | 給与 | 部門ごとの人件費 | CSVを組み替えて取り込む |
| KING OF TIME | 勤怠 | 原則は給与サービスへ | Web API |
4つとも、NetSuiteとの連携の案内は確認できませんでした（上記）。
API・連携基盤（iPaaS）・CSVの使い分けは、NetSuiteの連携方法ガイドで扱っています。
従業員番号を、共通の鍵にする
どのサービスとつなぐ場合も、最初に決めることがあります。
同じ人をどの番号で見分けるかです。
人事・給与・勤怠・NetSuiteの4つで、同じ従業員番号を使ってください。
氏名で突き合わせると、同姓同名や結婚による姓の変更で、必ずずれます。
部門も同じです。
部門のコードを4つでそろえておけば、Bの部門別の仕訳を作るときに組み替えが要りません。
番号をそろえる作業は、つなぎの開発より先に、表計算で済ませられます。
いちばん安く、いちばん効く準備です。
つまずく3つのパターン
パターン1：1本の仕訳のまま、部門の損益を見ようとする
現象
部門別の損益を出したら、人件費がすべて本社の部門に乗っていた。
営業部門や製造部門が、実際より利益が出ているように見える。
原因
Aの粒度（会社合計）で入れたまま、Bの粒度の情報を求めたためです。
避け方
2-4の表で、見たい損益から粒度を決めます。
部門別の損益を見るなら、最初からBを選びます。
パターン2：給与サービスとNetSuiteで、部門がずれている
現象
組織変更の翌月、人件費の取り込みでエラーが続いた。
給与サービスには新しい部門があり、NetSuiteにはまだない。
原因
組織変更のとき、どちらの部門を先に直すかを決めていなかったためです。
避け方
部門はNetSuiteで先に作り給与サービスを合わせる、という順番にします。
組織変更の手順書の最初に、「NetSuiteの部門を作る」を入れておきます。
従業員の情報の正本をどちらに置くかは、NetSuiteとOdooの人事・勤怠・給与の第6章で扱っています。
パターン3：工数が定着しないまま、案件別に配る
現象
案件別の採算を出したが、現場から「実感と違う」と言われた。
工数の入力が月末にまとめて行われ、中身が推測になっていた。
原因
Cの粒度は、工数の記録が正確であることが前提です。
その前提が整う前に、配る仕組みだけを作ったためです。
避け方
まずBで運用し、工数の記録を3か月ほど続けてからCに進みます。
工数の入力率を毎月見て、定着を確かめてから切り替えます。
ベンチャーネットならこう見る｜粒度は「守り→攻め→次へ」で上げる
型1：A・B・Cは、定着の3段階と重なる
ベンチャーネットは、NetSuiteが定着した先を「守り→攻め→次へ」の3段で考えます。
人件費の粒度も、この3段に沿って上げていきます。
- 守り（業務が回る）：Aの会社合計。決算が締まれば足りる
- 攻め（データで打つ）：Bの部門別。部門の損益で手を打つ
- 次へ（経営が変わる）：Cの案件・工程別。管理会計で案件の採算を見る
段を飛ばすと、パターン3が起きます。
工数の記録という「攻め」の土台がないまま、「次へ」の数字を作ることになるからです。
型2：作るか、手で入れるかを先に決める
粒度が決まったら、つなぎ方を「標準に合わせる／開発する／残す」の3つから選びます。
Aなら、月に1本の仕訳を手で入れるだけで済みます。
BやCで毎月の件数が多いなら、給与サービスの出力から仕訳を作る仕組みを開発します。
NetSuite認定パートナー（Solution Provider）であるベンチャーネットは、特定の製品に誘導しない立場を取っています。
NetSuite・Odoo・AIスクラッチ開発を扱い、SAPからのリプレイスにも対応しています。
この領域で引き受けるのは、粒度を決めること、NetSuite側の受け皿（部門・科目の対応と仕訳の形）を整えること、つなぎの開発の3つです。
給与計算・社会保険・年末調整そのものは、各サービスと社会保険労務士の領域です。
部門別の損益を見ていない会社には、Aで十分とお伝えします。
仕組みを作らず手で入れるほうが、保守は軽く済みます。
今日できること｜見たい損益を1つ決める
経営者と経理で、次の問いに答えてみてください。
「来月の経営会議で人件費が乗った損益をどの単位で見たいか」
- 会社全体でよい → A
- 部門ごとに見たい → B
- 案件や製品ごとに見たい → C（工数の記録があるかを見る）
答えが決まれば、つなぎ方の半分は決まります。
残りの半分は、5-6の従業員番号と部門のコードをそろえることです。
よくある質問
Q1. NetSuiteで、日本の給与計算はできますか
できません。
Oracleのヘルプでは、SuitePeople U.S. Payrollは米国の給与税にのみ対応すると書かれています（第1章）。
日本の給与計算は、国内の給与サービスで行います。
Q2. 人事・給与SaaSで、NetSuiteとの連携が用意されているものはありますか
この記事の4つには公式の案内を確認できませんでした（2026年9月23日時点）。
SmartHR・freee人事労務・KING OF TIMEは、APIを公開しています。
APIやCSVでつなぐ前提で設計します（第5章）。
Q3. 給与の明細をNetSuiteに入れるべきですか
入れないことをおすすめします。
会計に要るのは、部門や案件ごとの合計です。
個人の明細を入れると、権限の設計が重くなります（第3章）。
Q4. 人件費を案件ごとに配るには、何が必要ですか
工数の記録です。
勤怠ではなく、どの案件に何時間かけたかの記録が要ります。
工数の記録が定着してから、案件別に配る形に進んでください（2-3）。
Q5. 勤怠のデータは、NetSuiteに入れるべきですか
原則は給与サービスに渡します。
労働時間の計算と給与への反映は、国内のサービスの役割です。
NetSuiteに入れるのは、休暇の残数など、NetSuite側で使う情報に限ります。
Q6. 賞与も、同じ粒度で戻すべきですか
月々の給与と同じ粒度で戻すのが基本です。
賞与だけ会社合計で入れると、賞与の月だけ部門の損益が正しく見えなくなります。
給与と同じ部門の対応を使えば、追加の準備はほとんど要りません。
まとめ：人件費は、見たい損益の細かさで戻す
- NetSuiteの給与機能は、公式ヘルプ上米国の給与税のみ対応。日本の給与は国内サービスで計算する
- 人件費を戻す粒度は3つ。会社合計／部門別／案件・工程別
- 粒度は見たい損益で決める。多くの会社は部門別から始める
- 個人の明細はNetSuiteに入れない
- 締めの順番は勤怠→給与→仕訳の取り込み→配る→損益の確認
- 取り上げた4つのサービスは、NetSuiteとの連携の案内がない。API・CSVでつなぐ前提で設計する
給与をどこで計算するかは、ほぼ決まっています。
決めるのは、その結果をどの細かさで戻すかです。
来月の経営会議で見たい損益の単位を、まず1つ決めてください。
もう少し詳しく知りたい方へ
「人件費をNetSuiteにどう戻すか」の判断から、ご相談をお受けしています。
