毎月20日すぎ、総務の担当者が現場に電話をかけ始めます。「先週の残業がまだ入っていません」「この日の直行の時間を教えてください」。
集まった数字は勤怠の表に打ち込まれ、そのあと給与ソフトに入れ直される。締め日から支給日までは、この往復で埋まります。
この往復は、Odooと給与ソフトの持ち分を決めれば減らせます。給与計算はいまの給与ソフトに残し、その手前をOdooで一か所に集める形です。
Odoo（オドゥー：販売・在庫・会計などをつなぐ統合業務アプリ）には、日本の給与計算が公式に用意されていません。分担は前提で、決めるのは線を引く場所だけです。答えは「勤怠の確定」。確定の前はOdoo、確定の後は給与ソフトが持ちます。
たとえば職人がスマートフォンから現場と作業時間を入れれば、出退勤と工数が同じ入力から生まれます（設備工事業の想定シナリオ）。
線を引くと、たとえば次のことが変わります。
- 勤怠を二か所で持たず、締め日ごとの突き合わせが要らなくなる
- Odooで勤怠を集めれば、未提出の人が画面で分かり、催促の電話が減る
- 勤怠を工数とつなげば、現場ごとの人件費が見えるようになる
- 給与ソフトへ渡すのは、確定した集計結果だけになる
ただし、勤怠が工数とつながらない会社なら、給与ソフト側の勤怠製品で取るほうが合理的です。
では、自社はOdooで勤怠を取るべきか。見分け方はそもそもOdooで勤怠を取るべきかの表にあります。分担の良い点と負担は、この分担の良い点と、気をつけることに並べました。
CommunityとEnterpriseの区別について
この記事で中心になるのは、勤怠と工数の記録、データの書き出しです。これらは無料のCommunity版でも使えます。承認や外部APIは有償のEnterprise版の話のため、版ごとの対応範囲にまとめました。
給与の前後で、同じ勤怠を二度触っている
ブルシットジョブ（本人も意味がないと感じている仕事。人類学者デヴィッド・グレーバーが提唱した概念）は、怠慢から生まれません。仕組みのつなぎ目に、人が手で橋をかけているだけです。
給与まわりのつなぎ目は1つ。勤怠が集まる場所と、給与が計算される場所が別だという点です。そこに4つの型の仕事が生まれます。
- 転記：勤怠の集計結果を、給与ソフトに打ち直す
- 照合：勤怠表の合計と、給与ソフトに入った時間を見比べる
- 催促：締め日が来ても出てこない人に個別に連絡する
- 報告のための報告：残業時間の一覧を、給与とは別に作る
Odooの給与アプリの位置づけはOdooの給与計算（Payroll）と日本対応の現実で扱っています。ローカライズとは、国ごとの制度に合わせた設定のことです。Odoo公式の給与ローカライズ一覧にも、日本はありません（出典：Odoo公式ドキュメント「Payroll localizations」、2026年10月確認）。
就業規則を勤怠設定に落とす段取りは就業規則を勤怠設定に反映し、給与計算の手戻りを減らすが詳しいです。
線を引く場所は「勤怠の確定」
確定の前と後で、持ち主を変える
打刻や日報の入力から、上長の承認、修正のやり取りまでが「確定の前」です。毎日動き、人によって出し方も違う。
「確定の後」は月に1回だけ。確定した日数と時間から、支給額と控除額を計算する工程です。
性質が違うので、線は確定の一点で引きます。確定前はOdoo、確定後は給与ソフトの持ち分です。
確定を「誰が・いつ」押すかを先に決める
線を引くとは、責任の持ち主を決めることです。確定を誰が押すのかが曖昧だと、線はすぐ消えます。
決めるのは、締め日、確定の操作をする人、確定後の修正の扱いの3つ。
とくに3つ目が抜けがちです。後から間違いが分かったとき、どちらを直すのかを先に決めておきます。
渡すのは集計結果であって明細ではない
給与ソフトが欲しいのは、その人の1か月の日数と時間です。何時何分に打刻したかという記録は要りません。1件ごとの記録はOdooに残します。
freee・マネーフォワード・給与奉行は勤怠をどう受け取るか
受け取り口には2つの型があります。API（システム同士がプログラムで直接データをやり取りする窓口）と、CSV（項目をカンマで区切ったテキスト形式のファイル）です。
3社で形が違うため、公式ヘルプで確かめられた範囲を表にしました（出典：各社公式ヘルプ、2026年9月確認）。
| 給与ソフト | 勤怠の受け取り方 | 確認できた条件 | 公式に記載が見当たらない点 |
|---|---|---|---|
| freee人事労務 | APIで渡せる。取得と更新の窓口があり、1日に複数回の出退勤にも対応 | 打刻・勤怠を管理する機能を持つ | CSVで取り込む場合の形式・上限 |
| マネーフォワード クラウド給与 | API連携に対応する勤怠サービスの一覧がある。同ブランドのクラウド勤怠はAPIキーで接続。CSVの口もある | 従業員番号が両側で一致すること。CSVは項目名が給与計算画面の名称と完全一致すること | 一覧にない外部システムのCSVを受け入れられるか。クラウド給与の公開API |
| 給与奉行クラウド | 勤怠は受入のみ。カンマ区切りまたはタブ区切りのファイルで渡す | 勤怠は「受入のみ可能」との記載。2MBは汎用データ受入の手順書の値 | 勤怠受入時のファイルサイズ上限。開発者が直接呼べる公開API仕様 |
なお、freee人事労務の打刻・勤怠がどのプランで使えるかは、公式での確認が必要です。
Odoo側は、標準の書き出し機能で .csv か .xls に出せます（出典：Odoo公式ドキュメント「Export and import data」、2026年10月確認）。問題は、その形が相手の受入形式に合うとは限らないことです。
この形合わせは、毎月手で直す仕事になりがちです。AIに任せる考え方はAPI連携がなくてもAIでつなぐにあります。
そもそもOdooで勤怠を取るべきか
この問いを飛ばしてはいけない
ここまで読むと、Odooで勤怠を取る前提に見えるかもしれません。その前提こそ、検討すべき論点です。
freeeもマネーフォワードもOBCも、勤怠の製品を持っています。マネーフォワード クラウド勤怠は、確定した勤怠をクラウド給与へAPIで渡す構成が公式にあります。奉行Edge 勤怠管理クラウドから給与奉行iクラウドへの勤怠連携も、公式に記載のある構成です。
同じブランドで完結するなら、形を合わせる工程は生じません。
判断軸は「勤怠が工数とつながるか」
分かれ目は、勤怠が工数（どの案件に何時間かけたかの記録）とつながる必要があるかどうかです。
つながらないなら、給与ソフト側の勤怠製品で取るのが合理的。給与のためだけの記録を、別の場所に置く理由はありません。
つながるなら、Odoo側に置く意味が出ます。同じ時間を給与の材料としても、案件ごとの原価としても使えるからです。工数はOdooの工数管理（Timesheets）で扱っています。
会議でそのまま使える見分け方
次の表で、自社がどちらに近いかを見てください。「Odooで勤怠を取る」の列に当てはまるほど、Odoo側に置く利点が大きくなります。
| 確かめること | Odooで勤怠を取る | 給与ソフト側の勤怠製品で取る |
|---|---|---|
| 利益を見たい単位 | 案件ごと・現場ごとに知りたい | 会社全体・部門ごとで足りる |
| 見積と実績 | 見積の工数と実績を比べたい | 工数の比較はしていない |
| 働き方 | 同じ人が複数の案件をまたいで動く | 全員が同じ場所・同じ時間帯で働く |
| 勤怠のその先 | 給与と原価の両方に使う | 給与の計算にだけ使う |
ベンチャーネットは、この問いに「Odooに寄せましょう」とは言いません。右の列に当てはまる会社なら、そうお伝えします。勤怠アプリの機能はOdooの勤怠・休暇管理にまとめました。
人事・勤怠・給与をERPの比較からどう外すかは、NetSuiteとOdooの人事・勤怠・給与｜比較から外してよい業務が参考になります。規模が大きくNetSuiteも視野に入る会社でも、給与は国産ソフトに残す考え方は同じです。
計算した給与を、会計にどう戻すか
勤怠を渡す話の裏側に、もう1つの流れがあります。計算した給与を、仕訳として会計に戻す流れです。
マネーフォワード クラウド給与は、確定処理を行うとクラウド会計側で仕訳候補として扱える仕組みが公式に案内されています。
freeeにも、給与取引連携という機能名が公式ヘルプのページとして存在します。ただし詳細は確認できていないため、導入前の確認が必要です。
給与奉行クラウドは注意が要ります。給与明細や給与仕訳を外部へ出す手段と形式について、公式に記載が見当たりません。奉行製品連携のページの連携先にも、勘定奉行は含まれていませんでした。
これは「できない」という意味ではなく、記載が見当たらないというだけです。奉行の組み合わせなら、給与仕訳の渡し方を販売元へ確認してください。
AIをあいだに置くとき、どこまで任せるか
この分担では、月に一度ファイルの形を合わせる工程が残ります。AIが得意な領域ですが、任せる範囲には線を引けます。
任せてよいこと
- 項目名を相手の名称に置き換える
- 列の並びと日付の書き方を受入形式にそろえる
- 先月と今月を比べ、人数や合計時間の差を一覧にする
- 差が大きい行を確認候補として挙げる
任せてはいけないこと
- 確定していない勤怠を、確定したものとして渡す
- 中身を人が見ないまま、給与ソフトに取り込む
- 欠けている時間を、AIに推測で埋めさせる
給与は、間違えると取り返しがつきにくいデータです。支給してしまえば、訂正は次月以降の調整になる。最後の確認は人が持ちます。
勤怠データには、従業員の氏名と働いた時間が入ります。外部のAIサービスに渡してよいかは、会社として判断すること。氏名を社員番号に置き換える運用も選べます。
AIにどこまで社内のデータを見せるかを、権限ゼロから広げる考え方で書いたのがAIに会社のデータを、どこまで渡すかです。
Odoo Community版とEnterprise版の対応範囲
| 機能 | Community版 | Enterprise版 |
|---|---|---|
| 勤怠（出退勤の記録） | 使える | 使える |
| 工数（案件ごとの時間） | 使える | 使える |
| 従業員台帳の基本 | 使える | 使える |
| データの書き出し・取り込み | 使える | 使える |
| 経費精算（申請・精算の基本） | 使える | 使える |
| 承認・文書管理 | — | 使える |
| 会計のフル機能・Studio・AI | — | 使える |
| 外部API | — | カスタムプランで使える |
| 給与計算（日本向け） | 提供されていない | 提供されていない |
なお、版ごとの対応範囲は改定されることがあります。導入を検討する段階で、Odoo公式のエディション比較ページで最新の内容をご確認ください。
表のいちばん下が、この記事の出発点です。日本向けの給与計算は、版を上げても解決しません。
一方で、勤怠・工数・書き出しは両方の版で使えます。そのため、この分担はCommunity版でも組めるのです。
想定シナリオ（匿名）
たとえば、従業員35名の設備工事業の会社を考えてみます。現場は常時8か所から10か所が動き、職人は朝、事務所に寄らず現場へ直行する。
いまの勤怠は、紙の日報を回収して事務が表計算ソフトに入力する形です。締め日を過ぎても3割ほどが出てこないため、電話で催促しています。
もう1つの課題は、現場ごとの利益が見えないこと。材料費は請求書から拾えますが、人件費は現場に割り振られていません。
ここで分担を設計します。Odooには勤怠と工数、プロジェクトを入れる。職人はスマートフォンから、その日の現場と作業時間を入力します。出退勤と工数が、同じ入力から生まれる形です。
給与ソフトは残します。締め日の翌日に現場責任者が確認して確定し、集計結果だけを書き出して取り込む流れです。形を合わせる部分はAIに任せ、差分を事務が確認します。
消える作業は3つ。紙の日報の打ち直し、出てこない人を追う電話、給与ソフトへの二度目の入力です。代わりに、現場ごとの人件費が見えるようになります。
現場別の原価を求めない会社なら、話は別です。その場合は給与ソフト側の勤怠製品を使い、Odooには販売・購買・在庫だけを入れるほうが軽く済みます。
よくある2つの失敗
失敗1：勤怠を両方で取り、どちらが正か分からなくなった
Odooに勤怠を入れたあとも、給与ソフト側の勤怠機能を止めなかった、という形で起きます。最初の数か月は、問題なく見えるものです。
ずれ始めるのは、修正が片方だけに入ったとき。そこから毎月「どちらが正しいか」を確かめる作業が生まれます。対策は、入力口を1つに決めることです。
失敗2：締め日と給与計算日の関係を決めずに動かした
日付の設計を後回しにしたまま、運用を始める失敗です。勤怠の締め日、確定する日、給与ソフトへ渡す日、計算を実行する日。
この4つは連なっており、1つずれると後ろがすべてずれます。とくに問題になるのが確定後の修正。対策は、運用前に4つの日付を決め、修正手順を1枚にまとめることです。
給与ソフトを残したまま線を引く、ベンチャーネットの確かめ方
ERP導入支援を手がけるベンチャーネットは、給与ソフトの入れ替えから話を始めません。いまの給与ソフトを残す前提で、次の順に確かめます。
- いまの二度手間を書き出す：転記・照合・催促・報告のための報告が、誰に月何時間かかっているかを並べます。まず「見える化」です。
- 勤怠と工数をつなぐ必要があるかを決める：勤怠をOdooで取るかの見分け方の表で、現場別・案件別の原価を本当に見たいかを経営者と確かめます。不要なら、勤怠は給与ソフト側の製品に任せる案を出します。
- 確定の持ち主と4つの日付を決める：締め日・確定日・受け渡し日・計算日と、確定後の修正手順を1枚にします。ここはシステムより先に決める経営の約束事です。
- 受入形式を1か月分で試す：Odooから書き出した集計結果を、実際の給与ソフトの受入形式に合わせて試します。記載が見当たらない点は販売元へ確認します。
- 合わない部分は合わないと伝える：標準機能に業務を合わせる（Fit to Standard）のが基本です。それでも無理が残る部分は、そのままお伝えします。
この順番にしているのは、ERPが給与ソフトの置き換えではなく、経営の数字をつなぐ仕組みだからです。ベンチャーネットはNetSuite・Odoo・AIスクラッチ開発を扱うため、Odooありきでは進めません。
AIスクラッチ開発で受け渡しを組む選択肢もあります。ただしライセンスが不要でも、開発費と保守費は別途かかる。規模と要件を見て、どれが無理なく続くかで振り分けます。
この分担の良い点と、気をつけること
給与ソフトを残し、勤怠の確定で線を引く分担には、得られることと、先に引き受ける負担があります。
良い点は、次の5つです。
- 突き合わせが要らなくなる：確定前は一か所で集め、確定後の数字だけを一方向に渡す
- 給与計算はいまのソフトに残せる：日本の制度に沿った計算は給与ソフトが持ち、入れ替えから始めずに済む
- 現場ごとの人件費が見える：勤怠を工数とつなげば、同じ時間を給与の材料にも案件の原価にも使える
- 1件ごとの記録はOdooに残る：給与ソフトへ渡すのは集計結果で、打刻の記録はOdooに置いておける
- Community版でも組める：勤怠・工数・書き出しは、両方の版で使える
気をつけることは、次の4つです。
- 形合わせの工程が残る：3社で受け取り口の形が違い、月に一度ファイルの形を合わせる
- 確定の持ち主と日付を先に決める：締め日・確定日・受け渡し日・計算日と、確定後の修正手順を決めておく
- 入力口は1つに絞る：給与ソフト側の勤怠機能を止めないと、どちらが正か分からなくなる
- APIでの受け渡しは版を選ぶ：外部APIはEnterprise版のカスタムプランが要るため、Community版ではファイルでの受け渡しが現実的
両方を1枚の図に並べました。
入力口と日付の決め方でつまずく例は、よくある2つの失敗に書きました。
Odooの給与計算と勤怠連携のよくある質問
Odooだけで給与計算まで完結させることはできませんか？
できません。Odooの給与計算は、日本のローカライズが公式に提供されていないためです。日本の制度に沿った計算なら、給与ソフトとの分担が前提になります。
勤怠をOdooで取ると決めた場合、給与ソフト側の勤怠機能はどうなりますか？
使わない設定にします。二か所で持つと、どちらが正しいかを確かめる作業が毎月生じるためです。契約の扱いは販売元にご確認ください。
給与奉行クラウドから勘定奉行クラウドへ、給与仕訳は自動で流れますか？
公式には記載が見当たりません。連携先一覧に勘定奉行が含まれていないためです。できないという意味ではありませんが、導入前の確認が必要です。
Community版でもこの分担は組めますか？
組めます。勤怠・工数・書き出しは両方の版で使えるためです。ただし外部APIはEnterprise版のカスタムプランが必要なため、ファイルでの受け渡しが現実的です。
Odooと給与ソフトで分担するメリットは何ですか？
勤怠の突き合わせが要らなくなることです。
確定前の勤怠はOdooの一か所で集め、確定した集計結果だけを給与ソフトへ渡します。給与計算はいまの給与ソフトに残せます。勤怠を工数とつなげば、現場ごとの人件費も見えます。良い点と負担の一覧は、この分担の良い点と、気をつけることにあります。
まとめ：給与計算は勤怠の確定で分担する
Odooと国産給与ソフトの分担は、次の5点にまとまります。
- Odooに日本向けの給与計算はないため、給与ソフトとの分担が前提
- 線を引く場所は「勤怠の確定」。確定前はOdoo、確定後は給与ソフト
- 3社の受け取り口は形が違う。API・CSV・区切り文字つきファイルに合わせる
- Odooで勤怠を取るかは、勤怠が工数とつながるかで決める
- 形を合わせる作業はAIに任せ、確定と最終確認は人が持つ
給与の締め日前後は、総務にとっていちばん電話が鳴る時期でした。1年後の同じ時期、その電話は鳴っていません。誰がまだ出していないかは画面で分かり、職人も自分の時間を現場で入れているからです。
確定を押したあとは、集計結果を渡して取り込むだけ。空いた締め日の午後には、どの現場で工数が膨らんだのかを所長と話す時間が入ります。
もう少し詳しく知りたい方へ
ベンチャーネットは、ERP導入支援を手がける会社です。NetSuite・Odoo・AIスクラッチ開発を扱い、SAPからのリプレイスにも対応しているため、特定の製品に偏らない立場でご提案できます。
「いまの給与ソフトは残したまま、勤怠と工数の置き場所を決め直したい」という整理から、ご相談を承っています。
関連記事
