打刻忘れへの対策は、起きた後の処理と、早く見つけて防ぐ運用をセットで決めます。起きたら実際の労働時間を確かめ、本人の修正申請→承認→記録の順で直します。勤怠管理システムで対策するなら、自動検知だけでなく通知先、修正申請の承認、修正履歴、締め後の編集ロックまで確認してください。
打刻忘れが発生する原因の多くは運用面にあります。出退勤の動線とタイムカードや打刻機の設置場所が合っていない、直行直帰やテレワークで打刻の習慣が付いていない、打刻の重要性が意識されていない、といった原因です。罰金や減給などのペナルティに頼る前に、原因に合わせて打刻の場所・方法・通知を見直すことが大切です。会社として給与計算の前に未打刻を見つけて直す流れを決めておけば、従業員と担当者の負担も小さくできます。
比較対象はSaaS Factsが公開している勤怠管理システム23製品で、国内市場全体ではありません。製品情報は2026年10月4日〜7日時点の公式ページに基づき、確認できた記載と条件の判定を分けています。
打刻忘れが起きたときの処理と、防ぐための4つの対策
対応の要点は次の3つです。
- 客観的な記録と本人への確認を基に、実際の始業・終業時刻を記録する。推測で埋めない。(厚生労働省)
- 実際に勤務した時間を、打刻がないことだけで欠勤扱い・未払いにしない。違約金としての罰金と、就業規則に基づく減給は区別する。(厚生労働省)
- 防止は、打刻方法の見直し、ルールの周知、締め前の確認、自動検知と通知の4つを組み合わせる。自動検知は打刻忘れを無くすものではなく、早く見つけて修正申請に回す仕組みと位置付ける。
起きたときの処理：事実の確認→本人の修正申請→承認→記録
- 事実の確認：PCの使用時間や入退室の記録を集め、本人に始業・終業の時刻を確認します。厚生労働省の「労働時間の適正な把握のために使用者が講ずべき措置に関するガイドライン」は、客観的な記録を基礎に確認・記録することを原則とし、自己申告と記録に著しい乖離があれば実態を調査して補正するとしています。(厚生労働省)
- 本人の修正申請：申請項目は、対象日、確認した時刻、理由、確認に使った記録の4つです。管理者による直接修正とは区別して記録しましょう。
- 承認：承認者は申請と確認資料を照合し、疑問点があれば本人へ戻します。上司と人事の両方で見るなら、打刻修正申請にその承認経路を設定できるかが選定条件です。
- 記録：修正前後の時刻、理由、修正者、承認者、処理日時を残し、締めにつなげます。
この流れは社内の運用案で、法令が特定のシステム操作を求めているわけではありません。後の章では、1の起点になる自動検知と通知、2・3の打刻修正申請と多段階承認、4の修正履歴と確定後の編集ロックを製品別に確かめます。
記録の保存について、労働基準法第108条は賃金台帳の調製・記入、第109条は労働関係書類の保存を定めています。保存期間は5年間に延長され、経過措置として当分の間は3年間です。(厚生労働省)(厚生労働省)
また、労働安全衛生法第66条の8の3は、医師の面接指導を実施するため、労働者の労働時間の状況を把握することを事業者に義務付けています。(e-Gov法令検索)
欠勤扱い・罰金はできない。減給は労働基準法第91条の上限内
第16条は、労働契約の不履行について違約金を定めたり、損害賠償額を予定したりする契約を禁じています。打刻忘れに対する「罰金」を、そのような契約で課すことはできません。(厚生労働省)
制裁としての減給には就業規則の根拠が必要で、第89条は制裁の種類・程度を就業規則の記載事項とし、第91条は、1回の額が平均賃金の1日分の半額、総額が一賃金支払期における賃金の総額の10分の1を超えてはならないと定めています。上限内なら個別の処分が当然に認められる、というわけでもありません。(e-Gov法令検索)
防ぐための4つの対策と、システムでできること・できないこと
- 打刻方法を働き方に合わせる：どの勤務場所・時間帯で忘れているかを整理し、動線上の打刻機、PC、スマートフォンを使う場面を決めます。在宅勤務や直行直帰でも迷わず操作できるかが確認点です。
- 打刻と修正申請のルールを周知する：打刻のタイミングに加え、忘れたときの連絡先、修正申請の期限、理由の書き方を伝えます。注意だけで終えず、本人が次に取る操作を示してください。
- 締め前に未打刻と未承認を確認する：月末に集中させず、日次・週次で未打刻を見る担当者を置きます。締め前は、承認待ちの修正申請も対象です。
- 自動検知と通知を修正申請につなげる：通知を本人へ直接届けるのか、管理者が一覧から督促するのかで、必要な機能が分かれます。
システムにできるのは、漏れを見つけて知らせ、修正を記録に残すところまでで、打刻そのものは本人が行います。SaaS Factsの判定では、23製品のうち「打刻漏れを自動検知できる」を満たすのは12製品、今回の調査範囲では確認できずが11製品です。
打刻漏れを自動検知できるか：勤怠管理システム23製品の判定
以下では公式ページの表記に合わせ、「打刻漏れ」を打刻忘れと同じ意味で使います。まず3条件（打刻漏れを自動検知できる・勤怠申請の多段階承認に対応・勤怠実績の修正履歴を記録できる）の判定を製品ごとに見渡し、次に条件ごとの表で記載を確かめます。
条件の判定と公式ページの記載を分けて見る
条件「打刻漏れを自動検知できる」の集計は、満たす12・条件付き0・満たさない0・今回の調査範囲では確認できず11です。
判定表はすべて「満たす→条件付き→満たさない→今回の調査範囲では確認できず」の順、同じ判定内は調査データの製品順で並べます。
| 製品 | 打刻漏れを自動検知できる | 公式ページの記載（補足） |
|---|---|---|
| CLOUZA（クラウザ） | 満たす | 個人用Webタイムレコーダーに打ち忘れのアラートを表示。出典 |
| COMPANY 勤怠管理 | 満たす | 打刻忘れなどを用いた任意のアラートを作成・通知。出典 |
| TeamSpirit 勤怠 | 満たす | 出退勤の打刻漏れを自動検知して本人へ通知。出典 |
| Universal 勤次郎 | 満たす | 従業員自身が打刻漏れに気づけるアラートを導入事例で記載。出典 |
| キンタイミライ | 満たす | 打刻忘れ・打刻漏れや誤打刻をアラートで検知。出典 |
| ジョブカン勤怠管理 | 満たす | 打刻の数が合わないなどのエラーを自動抽出・表示。出典 |
| ジンジャー勤怠 | 満たす | 打刻漏れを通知し、打刻修正申請を促す。出典 |
| タッチオンタイム | 満たす | 打刻忘れなどのエラー一覧と自動アラートメール。出典 |
| マネーフォワード クラウド勤怠 | 満たす | 未打刻・未承認を検知し、承認者に通知。出典 |
| レコル | 満たす | 打刻ミスなどをアラートで自動通知。出典 |
| 楽楽勤怠 | 満たす | 打刻漏れを従業員本人へ自動通知。出典 |
| 奉行Edge 勤怠管理クラウド | 満たす | 未打刻アラート・滞留アラートを記載。出典 |
| ADVANCE勤怠クラウド | 今回の調査範囲では確認できず | 打刻エラーの一覧表示。出典 |
| e-就業OasiS | 今回の調査範囲では確認できず | 客観的記録と自己申告時刻の乖離を警告表示。出典 |
| Edge Tracker 勤怠管理 | 今回の調査範囲では確認できず | 異常な勤怠データへのアラート。出典 |
| freee勤怠管理 | 今回の調査範囲では確認できず | 未登録勤怠などを可視化し、不備のある対象者をリスト化して督促。出典 |
| ICタイムリコーダー | 今回の調査範囲では確認できず | 打ち忘れ・異常勤怠を表示。出典 |
| KING OF TIME | 今回の調査範囲では確認できず | 今回の調査範囲では確認できず |
| koiki | 今回の調査範囲では確認できず | 打刻時のエラーを色別で表示。出典 |
| WiMS/SaaS 勤務管理システム | 今回の調査範囲では確認できず | 確認保留 |
| キンコン | 今回の調査範囲では確認できず | 打刻忘れを知らせるアラート。出典 |
| ハーモス勤怠 | 今回の調査範囲では確認できず | 通常と異なる打刻を事前検知してアラート。出典 |
| マネーフォワード クラウド勤怠Plus | 今回の調査範囲では確認できず | 打刻漏れのアラートを記載。出典 |
検知した打刻漏れは誰に、何で届くか
通知先または手段を公開情報で確認できた製品を、前表の順に並べました。打刻時のエラー表示や督促の記載は、打刻漏れの自動通知と区別しています。
| 製品 | 通知先・手段 | タイミング・対象など |
|---|---|---|
| CLOUZA（クラウザ） | 本人への画面表示、管理者による確認 | 個人用Webタイムレコーダーに表示。出典 |
| COMPANY 勤怠管理 | 本人・上司・人事へ注意喚起 | 任意の基準でアラートを作成、メール・チャットの別は今回の調査範囲では確認できず。出典 |
| TeamSpirit 勤怠 | 本人へメール、Slack・Teams | 前日の未打刻を「翌日の午前9時」などに通知、チャット連携では始業終業時刻の±60分以内の通知も記載。出典出典 |
| Universal 勤次郎 | 従業員自身がアラートで確認 | 通知手段・タイミングは今回の調査範囲では確認できず。出典 |
| キンタイミライ | 管理者が対象者を一覧確認、勤務者へ打刻時アラート | 問題のある打刻を打刻時に周知。出典 |
| ジョブカン勤怠管理 | 本人へ打刻修正依頼メール | 修正箇所を指摘して自動送付。出典 |
| ジンジャー勤怠 | 各従業員へメール・画面表示 | 打刻画面上部にもアラートを表示。出典 |
| タッチオンタイム | 管理者画面、従業員・管理者へメール | エラー一覧表示と自動通知。出典 |
| マネーフォワード クラウド勤怠 | 承認者へ通知 | 手段・タイミングは今回の調査範囲では確認できず。出典 |
| レコル | 本人・管理者が画面・メールで確認、本人はSlackでも受信 | Slack連携で自身の出退勤アラートを受信。出典出典 |
| 楽楽勤怠 | 本人へ自動通知、従業員・管理者の画面で確認 | 部門・部署ごとに確認し、打刻訂正の申請を促す。出典出典 |
| freee勤怠管理 | 不備のある従業員へツールで通知 | リスト化した対象者への督促、具体的な通知手段は今回の調査範囲では確認できず。出典 |
| koiki | 従業員が色別表示で確認 | 打刻した時のエラー表示。出典 |
表にない10製品は、判定表の記載欄にアラートの記載があっても、打刻漏れの通知先・手段は今回の調査範囲では確認できず。
通知は打刻忘れを無くすものではなく、本人が気づいて修正申請するまでを早めるものです。受け取った後の申請と承認まで運用に組み込んでください。
打刻修正申請と多段階承認を23製品で確認する
「申請できる」と「多段階で承認できる」を分ける
条件「勤怠申請の多段階承認に対応」は、満たす6・条件付き4・満たさない1・今回の調査範囲では確認できず12です。勤怠申請全般の判定なので、打刻修正に同じ経路を使えるかは記載欄と問い合わせで確かめます。
| 製品 | 勤怠申請の多段階承認に対応 | 公式ページの記載（補足） |
|---|---|---|
| e-就業OasiS | 満たす | 打刻漏れ申請、承認階層に制限なし。出典 |
| TeamSpirit 勤怠 | 満たす | 勤務時間修正申請、上長への1段階承認から多段階承認まで設定。出典出典 |
| Universal 勤次郎 | 満たす | シフト変更を園長→本部で二重承認する導入事例。出典 |
| マネーフォワード クラウド勤怠Plus | 満たす | 残業・休暇・遅刻などの申請と、多段階承認の経路設定。出典 |
| 楽楽勤怠 | 満たす | 打刻修正の承認ステップ設定、複数段階の承認に対応。出典出典 |
| 奉行Edge 勤怠管理クラウド | 満たす | 申請者→1次承認者→2次承認者→完了の設定例。出典 |
| Edge Tracker 勤怠管理 | 条件付き | ワークフローのバンドルにより多段階承認。出典 |
| ICタイムリコーダー | 条件付き | 時間外労働・休暇の申請、開発課長→開発部長の承認例。出典出典 |
| ジョブカン勤怠管理 | 条件付き | 手動打刻・打刻修正に管理者承認を求める設定、理由を付記する運用例。出典出典 |
| タッチオンタイム | 条件付き | 打刻漏れ・誤打刻の修正申請、最大5段階、申請時に承認者へ通知メール。出典出典 |
| CLOUZA（クラウザ） | 満たさない | 申請承認ワークフローオプションで打刻修正申請、承認段階は一段階のみ。出典 |
| ADVANCE勤怠クラウド | 今回の調査範囲では確認できず | 打刻修正申請、設定済みの代理承認者による承認。出典 |
| COMPANY 勤怠管理 | 今回の調査範囲では確認できず | モバイルの申請・承認を記載。出典 |
| freee勤怠管理 | 今回の調査範囲では確認できず | チャット内での申請・承認の導入事例。出典 |
| KING OF TIME | 今回の調査範囲では確認できず | ワークフロー（申請・承認）を記載。出典 |
| koiki | 今回の調査範囲では確認できず | 申請・承認あり。出典 |
| WiMS/SaaS 勤務管理システム | 今回の調査範囲では確認できず | 部門長承認(1~10段階)、部門長代理承認。出典 |
| キンコン | 今回の調査範囲では確認できず | チームリーダーを間に挟む承認フローの導入事例。出典 |
| キンタイミライ | 今回の調査範囲では確認できず | 勤務者自身の申請、管理者による承認。出典 |
| ジンジャー勤怠 | 今回の調査範囲では確認できず | 打刻修正の申請・承認、承認フローは最大10段階まで設定可。出典出典 |
| ハーモス勤怠 | 今回の調査範囲では確認できず | 有料プランの届出申請ワークフロー。出典 |
| マネーフォワード クラウド勤怠 | 今回の調査範囲では確認できず | 残業・有休などのWeb申請。出典 |
| レコル | 今回の調査範囲では確認できず | 打刻忘れなどの申請・承認、承認後に勤務表を更新。出典 |
WiMS/SaaS 勤務管理システムの1~10段階、ジンジャー勤怠の最大10段階のように記載欄に段階数があっても、判定は変えていません。出典出典 「条件付き」は追加費用が必要という意味に限らないため、打刻修正への適用、承認段階、必要なオプションを問い合わせ票に残します。
修正履歴と確定後の編集ロックを確認する
修正を認めるなら、誰がいつ直したかの記録と、締め後に動かせない仕組みを対で確認します。
勤怠実績の修正履歴：判定と関連する記載
条件「勤怠実績の修正履歴を記録できる」は、満たす3・条件付き0・満たさない0・今回の調査範囲では確認できず20です。
関連する「操作・修正履歴の記録」を公開情報で確認できたのは7製品。次表は、満たす3製品、判定は今回の調査範囲では確認できずでも記載がある4製品、確認保留の1製品です。申請履歴やシフトの変更履歴は、勤怠実績の修正履歴と同じではありません。
| 製品 | 勤怠実績の修正履歴を記録できる | 公式ページの記載（補足） |
|---|---|---|
| ICタイムリコーダー | 満たす | 修正履歴を保存。出典 |
| レコル | 満たす | 勤務表で勤務修正履歴を確認。出典 |
| 楽楽勤怠 | 満たす | 打刻履歴・修正履歴・承認履歴をログとして保持。出典 |
| キンコン | 今回の調査範囲では確認できず | 外部の業務アプリとの連携でシフト管理の作成や変更履歴の管理を行う記載（勤怠実績の修正履歴の記載ではない）。出典 |
| キンタイミライ | 今回の調査範囲では確認できず | 管理者の修正に修正者ID・修正時刻を記録、2ヶ月前までの修正内容は画面・CSV、修正時刻はCSVで確認、3ヶ月以上前は依頼により調査・出力に対応するケースあり。出典 |
| ジョブカン勤怠管理 | 今回の調査範囲では確認できず | 導入事例に、申請関係のログを残せるようになったとの記載。出典 |
| ジンジャー勤怠 | 今回の調査範囲では確認できず | 申請・承認の履歴を記録。出典 |
| ハーモス勤怠 | 今回の調査範囲では確認できず | 操作・修正履歴の記録は確認保留 |
表にない15製品は、判定・関連する記載とも今回の調査範囲では確認できず。
確定後の編集ロックを公開情報で確認できた3製品
調査データの製品順です。履歴の保存と締め後の編集制限は、別の項目として見てください。
| 製品 | 公式ページの記載 |
|---|---|
| TeamSpirit 勤怠 | 日ごと・月ごとの実績を確定・ロック、未打刻や必須の申請漏れ、工数との差異がある場合は確定できない設計。出典出典 |
| キンタイミライ | 日ごとの確認・編集ロック、勤怠締めによる編集ロック。出典 |
| ジョブカン勤怠管理 | 締め日設定で確定実績の編集を制限、締め処理画面でも打刻漏れ・未承認申請を確認。出典 |
上記以外の20製品について、勤怠確定後の編集ロックは今回の調査範囲では確認できず。ロック解除の権限や、解除後の再承認も問い合わせ事項です。
打刻忘れを減らす運用ルールの雛形
空欄を埋めて社内の案に使ってください。期限や担当者は自社で決める値で、製品の仕様ではありません。
通知のタイミングと受け手を決める
- 締め日：［毎月 日］。締めまでの確認期間：［ 営業日］。
- 通知：［当日の終業後／翌朝／その他］の［ 時］。
- 通知先：［本人］、未処理時の確認担当：［管理者名・部署］。
- 通知手段：［画面／メール／チャット］。未読・未処理時の督促方法：［ ］。
修正期限・理由・承認者をそろえる
- 本人の修正申請期限：［翌営業日／週次締めなど］。
- 申請内容：対象日、実際の時刻、確認資料、修正理由。
- 承認者：［直属上司→人事など］。不在時の代理担当：［ ］。
- 承認期限：［ ］。差し戻し時の連絡先：［ ］。
理由を記入する運用と、システムで理由の必須入力を設定できることは別です。必須化の可否は問い合わせてください。
締め前チェックと確定後の修正を決める
- 締め前：［担当者］が未打刻、未承認、差し戻し中の申請を確認。
- 未解決の記録：推測で埋めず、本人と承認者へ確認。
- 確定後：［担当者］へ修正依頼し、解除権限、理由、修正内容、再承認を記録。
- 履歴の保管：［保存先・担当者・必要期間］を指定。
制裁規定は勤怠修正の手順と分けて確認する
就業規則の制裁の種類・程度と減給の上限を確認し、規定の見直しや実際の減給の判断は社会保険労務士・弁護士に確かめます。勤怠データを正しく直す処理は、それとは分けて進めます。(e-Gov法令検索)
確認できなかった項目を問い合わせ票に移す
項目ごとの公開状況は、自動検知が「公開情報で確認21・確認保留1・今回の調査範囲では確認できず1」、申請・承認が「23・0・0」、操作・修正履歴が「7・1・15」、編集ロックが「3・0・20」です。条件の判定数とは集計の対象が異なります。
確認保留は、関連する記載はあったものの確定値として掲載できないと判断した項目です。表で「確認保留」とした2製品は、記載の内容から問い合わせます。
対象製品と質問を対応させる
問い合わせの冒頭に「締め日［ ］、承認経路［ ］、打刻方法［ ］、修正理由の記録［必要／不要］」を添え、対象製品は各表から選んで次の質問を転記してください。
| 確認すること | 対象製品・調査状況 | 聞き方の例 |
|---|---|---|
| 打刻漏れの自動検知 | 自動検知表で「今回の調査範囲では確認できず」の11製品 | 出勤・退勤の片方がない場合、自動で抽出しますか。休暇・夜勤はどう扱いますか。 |
| 通知先・手段・時刻 | 通知一覧で「今回の調査範囲では確認できず」とした欄と、表にない10製品 | 本人へ翌朝、未処理なら管理者へ通知する運用を設定できますか。 |
| 打刻修正と承認経路 | 多段階承認表で「今回の調査範囲では確認できず」の12製品、条件付き4製品 | 打刻修正を上司→人事で承認できますか。対象申請と必要なオプションを教えてください。 |
| 申請期限・理由の必須化 | 23製品とも今回の調査範囲では確認できず | 期限の設定と理由の必須入力はできますか。期限後の訂正はどう処理しますか。 |
| 修正履歴・保存期間・出力 | 判定が「今回の調査範囲では確認できず」の20製品、満たす3製品も期間・形式を確認 | 誰が、いつ、何を変更したかを何年分、どの形式で出せますか。本人と管理者の修正を区別できますか。 |
| 編集ロック・解除権限 | ロック表にない20製品、掲載3製品も解除権限を確認 | 締め後の編集を制限できますか。誰が解除でき、解除と再修正の履歴は残りますか。 |
キンタイミライは、前表の期間と条件を前提に、自社が必要とする過去データの保存・提出方法まで確認が必要です。出典
比較表と自社条件で絞るページで候補を残す
先に通知・申請・承認・確定の担当者と期限を決め、自動検知・多段階承認・修正履歴などの自社条件で絞るへ進みます。残った候補は、23製品の比較表で打刻方法・給与計算ソフトとの連携・保存期間の値と出典を確認すると、本稿で扱っていない条件も整理できます。
候補各社へ問い合わせ票を送り、トライアルやデモを使える場合は、自社の打刻方法で「打刻漏れの通知→本人の修正申請→承認→履歴確認→確定後の編集制限」を確かめてから導入を判断してください。料金や個別事案の法的判断は本稿の対象外です。