稼働報告書の書き方｜請求の根拠として残す
稼働報告書の書き方を調べている時点で、たいていは請求の直前か、請求のあとで揉めた直後です。「先月の作業内容をもう少し詳しく書いてください」と差し戻された、「この工数は何に使ったのか説明できますか」と経理から聞かれた、あるいは自分が発注する側で、届いた報告書を見ても支払ってよいのか判断がつかない。どれも書式の問題に見えて、実際には「何を証明するための書類なのか」が決まっていないことから起きています。
この記事では、5人から数十人のチームで進行のとりまとめをしている人に向けて、稼働報告書を請求の根拠として使える形に組み立てる方法を整理します。書く項目、承認する人、提出の締め、保管の期間。この4つを先に決めておくと、月末の差し戻しはほとんど消えます。あわせて、稼働の記録が表計算ファイルとチャットに散っている状態で何が起きるか、道具のどこで詰まっているのかを見極める観点まで扱います。なお、帳簿や証憑の保存年数、インボイス制度の要件については、法令の解釈にあたるため断定を避け、確認先を示す形にとどめます。
稼働報告書が必要になる場面と、その背景
稼働報告書は、決まった様式が法律で定められた書類ではありません。契約の当事者どうしが「この内容で報告する」と合意して使う、当事者間だけの書式です。だからこそ現場ごとに形がばらつき、書き方を調べる人が絶えません。
必要になる場面はおおむね3つに分かれます。1つ目は、準委任契約や派遣契約のように、稼働した時間に対して報酬を払う契約です。この場合、稼働報告書はそのまま請求金額の計算根拠になります。時間が1件でも違えば請求額が変わるため、報告書は請求書の付属資料ではなく、請求書の中身そのものです。2つ目は、請負契約や成果物単位の契約で、進行の説明資料として使う場面です。この場合の稼働報告書は金額に直結しませんが、追加作業が発生したときに「もともとの範囲を超えている」ことを示す材料になります。3つ目は、社内向けの原価管理です。プロジェクトごとに人の時間をいくら積んだかを把握するために、社員にも同じ書式で出させる会社があります。
書き方の悩みが深くなるのは1つ目の場面です。時間で払う契約では、稼働報告書に書かれた数字が確定した瞬間に金額が確定します。単価5,000円の案件で月160時間の稼働なら80万円、精算幅を下回って130時間になれば控除が発生する、という具合です。数字の根拠を後から説明できない報告書は、支払う側にとって承認できない書類になります。
リモートワークが定着してから、この書類の重みは増しています。同じ場所で働いていれば、その人がいつ来ていつ帰ったかは周囲が知っています。離れて働くと、その暗黙の証拠が消えます。残るのは本人が書いた記録だけです。だから発注する側は記録の粒度を上げたくなり、受ける側は書く手間が増えるという緊張が生まれます。よく聞くのは、粒度を上げすぎた結果、報告書を書くために30分を毎日使うようになり、その30分をどう請求するかで再び揉めた、という話です。
背景として押さえておきたいのは、稼働報告書が「支払いを守る書類」であると同時に「請求を守る書類」でもあるという点です。発注する側から見れば、払った金額の説明責任を果たす証憑です。受ける側から見れば、支払いを渋られたときに「この時間は確かに働いた」と示す唯一の材料です。どちらか一方の都合だけで設計された書式は、必ずもう一方から差し戻されます。
稼働報告書は何を証明する書類か
書式を決める前に、その報告書が何を証明する紙なのかを言語化しておくと、迷いが減ります。稼働報告書が証明するのは、次の3つです。
第一に、時間の量です。いつからいつまで、合計で何時間働いたか。これが金額に直結します。第二に、その時間が契約の範囲内の作業に使われたことです。時間だけあっても、契約と無関係な作業に使われていたのなら支払いの根拠になりません。第三に、その内容を発注者が確認して受け入れたことです。承認の記録がない報告書は、一方の言い分にすぎません。
この3つのうち、現場で最も抜けるのが3つ目の承認です。作成側は時間と内容を丁寧に書き、メールで送って終わりにします。受け取った側は読んで問題がなければ何も返さない。この状態で数か月が過ぎ、支払いを巡って認識の差が出たときに、承認した記録がどこにもないことに気づきます。「送った」という事実と「受け入れられた」という事実は別物です。
証明の対象を意識すると、書式に入れるべき項目が自動的に決まります。時間の量を証明するには日付と時刻と合計が要ります。契約の範囲内であることを証明するには契約名や案件名と作業内容が要ります。受け入れられたことを証明するには承認者の欄と承認日が要ります。逆に言えば、この3つの証明に寄与しない項目は、書く手間を増やしているだけです。天気やその日の気分を書く欄がある報告書は珍しくありませんが、証明には何も足していません。
もうひとつ、稼働報告書と混同されやすい書類にタイムシートと作業日報があります。タイムシートは時刻の記録に特化した表で、作業内容は最小限です。作業日報はその日に何をしたかの記述が主で、時間は補足です。稼働報告書は、その両方を月次や週次でまとめ、請求に耐える形に整えたものと考えると位置づけがはっきりします。日々の記録をタイムシートと日報で取り、締めのタイミングで稼働報告書に集約する。この2段構えが、書く負担と証明力のバランスとしては現実的です。
現場でしばしば起きるのは、この2段が分離せず、月末にまとめて思い出しながら書いているケースです。20日前の作業内容を正確に思い出せる人はほとんどいません。記憶で書いた報告書は、詰められたときに崩れます。日々どこかに記録が落ちている状態を先に作らないと、書き方をいくら工夫しても精度は上がりません。
稼働報告書に書く項目
項目は多ければよいものではありません。証明に寄与するものだけを残し、書く時間を短くしたほうが、結果として続きます。
契約と期間を特定する情報
報告書の先頭には、どの契約のどの期間の話なのかを一意に特定できる情報を置きます。具体的には、報告対象の年月または期間、案件名または契約名、契約番号や発注書番号、氏名または会社名、提出日です。
ここが曖昧だと、同じ人が複数の案件に関わっているときに集計が破綻します。ある会社では、フリーランスに3つの案件を並行で頼んでいて、報告書には氏名と月しか書かれていませんでした。案件ごとの原価が出せず、どの案件が赤字なのか半年間わからないままだった、という話が出ています。案件名は必ず入れ、可能なら発注書の番号まで紐づけておくと、経理側の突合が一気に楽になります。
期間の書き方も統一が要ります。「9月分」だけでは、月末締めなのか20日締めなのかが読み取れません。「2026年9月1日から2026年9月30日まで」のように、開始日と終了日を明記する形が安全です。締め日が月末以外の運用をしている取引先が1社でもあると、この省略が後で事故になります。
稼働時間の記録
時間の欄は、日付、開始時刻、終了時刻、休憩時間、当日の稼働時間、そして期間の合計時間で構成します。合計だけを書いた報告書は、内訳を求められた瞬間に作り直しになります。
丸め方のルールは、書式を配る前に決めて明文化しておきます。15分単位で切り捨てるのか、30分単位で四捨五入するのか、分単位でそのまま積むのか。決まっていないと、作成者ごとに違う丸め方をして、合計が合わなくなります。1日あたり数分の差でも、20営業日積み上がれば1時間を超えます。単価5,000円なら1か月で5,000円以上の差になり、これが毎月続きます。
精算幅のある契約では、下限と上限も報告書の中に併記しておくと差し戻しが減ります。「精算幅140時間から180時間、当月稼働165時間、控除および超過なし」と1行あるだけで、承認する人が電卓を叩く必要がなくなります。承認者の作業時間を減らす工夫は、そのまま承認の速さに変わります。
深夜や休日の稼働がある契約では、その時間帯を分けて集計できる形にしておきます。単価が変わる区分を後から手作業で仕分けるのは、月末の作業として最も事故が起きやすい部分です。
作業内容の記述
金額の根拠としては時間が主役ですが、差し戻しの原因になるのはほぼ作業内容の欄です。「対応」「作業」「打ち合わせ」だけが並んだ報告書は、承認する側が判断できません。
書き方の目安は、後から見た第三者が「その時間が契約の範囲内である」と判断できる程度の具体性です。「資料作成」ではなく「10月定例向けの進捗資料の作成、グラフ4点の差し替え」まで書く。「打ち合わせ」ではなく「先方担当2名との仕様確認、議事メモ作成まで」と書く。固有名詞と数量が入ると、途端に判断できる文章になります。
一方で、書きすぎも続きません。1日の作業を10行に分けて書く運用は、最初の2週間は守られ、その後崩れます。現実的な粒度は、1日あたり2行から4行程度、時間の大きい塊ごとに1行という形です。細かく分けたいなら、記述を増やすのではなく、タスクの識別子を書く方式に切り替えたほうが持ちます。タスクの管理をしている場所にカードや課題の番号があるなら、報告書には番号と時間だけを書き、内容の詳細はそちらを見てもらう。二重に書く作業がなくなります。
成果物と進捗の記載
時間で払う契約であっても、その期間に何が前に進んだのかを1ブロック分書いておくと、報告書の説得力が変わります。完成したもの、着手して途中のもの、次の期間に持ち越すもの。この3分類で数行あれば十分です。
進捗をパーセントで書くのは避けたほうが無難です。定義が共有されていないため、90%のまま1か月動かないという現象が起きます。「初稿提出済み、修正待ち」のように、成果物の状態で表したほうが、書く側も読む側もずれません。
特記事項と時間の増減
想定外の作業が発生した月は、必ず特記事項に理由を書きます。「先方都合により仕様変更が2回発生、再作業に12時間」のように、増えた原因と時間をセットで書く。ここを書かずに合計だけが増えていると、承認する側は差し戻すしかありません。
逆に稼働が少なかった月も、理由を書いておくと後が楽になります。「先方確認待ちにより着手できない期間が5営業日発生」と残っていれば、次の契約更新時に精算幅を見直す材料になります。
誰が承認するか
書式が整っていても、承認の線が決まっていないと稼働報告書は機能しません。ここは書き方の話に見えないため後回しにされがちですが、差し戻しと支払い遅延の大半はここから出ます。
承認する人を1人に決める
承認者は1人に決めます。複数人の合議にすると、誰も最終判断をせず、報告書が滞留します。「部長も見たほうがいい気がする」という遠慮が入った瞬間、月末の3営業日が消えます。
決めるべきは、承認する人の役職ではなく「その稼働内容が契約の範囲内かどうかを判断できる人」です。多くの場合、日々やり取りしている現場の責任者がそれにあたります。経理は金額の妥当性を確認できても、その作業が必要だったかは判断できません。逆に現場の責任者は内容を判断できても、契約の精算幅を把握していないことがあります。だから実務では、内容の承認と金額の確認を分け、内容は現場、金額は経理という2段にするのが安定します。この2段は合議ではなく、順番が決まった直列の処理です。
承認者が不在になる場合の代理も、先に決めておきます。1人の休暇で支払いが1か月ずれる運用は、受ける側にとって死活問題になります。代理承認者を書式の中に欄として持っておくと、その場で判断できます。
承認の記録を残す
承認は、記録に残る形で行います。口頭で「大丈夫です」と言われただけの承認は、あとから確認できません。
残し方は、報告書の中に承認者名と承認日の欄を設けるのが基本です。紙で回すなら押印、電子で回すなら承認者のアカウントで状態を変える、メールなら「承認します」という文言を含む返信を保存する。どの形でもよいのですが、方法を1つに決めて全員が同じ形で残すことが重要です。人によって残し方が違うと、後から探すときに全経路を辿ることになります。
差し戻す場合も同じで、差し戻した理由を記録に残します。「作業内容が不明瞭なため差し戻し、9月12日から14日の記載を詳細化してください」と書いてあれば、次の月から同じ差し戻しが起きません。理由を書かずに突き返すと、作成者は何を直せばよいか分からず、同じ内容で再提出してきます。ここで往復が2回3回と増えるのが、月末が忙しくなる典型的な原因です。
承認の履歴が積み上がると、それ自体が資料になります。どの案件でどの月に差し戻しが多いか、承認までに何日かかっているか。この数字が見えると、書式の問題なのか、提出時期の問題なのか、承認者の負荷の問題なのかを切り分けられます。
いつまでに出すか
締めの設計は、書式そのものより支払いの速さに効きます。ここが曖昧だと、書き方をどれだけ整えても入金は遅れます。
決めるべき日付は4つです。稼働の締め日、報告書の提出期限、承認の期限、請求書の提出期限。この4つが順番に並び、それぞれ何営業日空けるかを合意しておきます。
たとえば月末締めの契約なら、稼働の締めが月末日、報告書の提出が翌月2営業日以内、承認が翌月5営業日以内、承認後に請求書を発行、という並びが現実的です。承認と請求書発行の順序は特に重要で、承認前に請求書を出させる運用にすると、差し戻しのたびに請求書を作り直すことになります。受ける側の手間が二重になり、金額の異なる請求書が複数枚存在するという、経理にとって最悪の状態が生まれます。
締めが月末以外の取引先が混ざる場合は、契約ごとに締め日の一覧を作って共有します。よく聞くのは、20日締めの案件と月末締めの案件を同じ書式で回していて、20日締めの月に11日分の稼働が抜け落ちていた、という事故です。書式の中に対象期間を明記する運用にしておけば、この抜けは提出時点で気づけます。
提出が遅れる原因の多くは、作成者の怠慢ではなく、締め日に必要な情報が揃っていないことです。月末最終日の稼働は、その日の終わりにならないと確定しません。その日に集計して翌営業日に提出しろという設計は、実質的に無理を強いています。2営業日から3営業日の余裕を持たせたほうが、結果として全体は速く回ります。
督促の担当も決めておきます。誰も督促しない運用では、遅れる人は毎月遅れます。とりまとめる立場の人が全件を目視で追う形にすると、案件が10件を超えたあたりで破綻します。提出されたかどうかが一覧で見える状態を作り、未提出だけを拾って声をかける形にすると、確認の時間は数分で済みます。
保管の期間と保管の形
稼働報告書は、提出して承認されたら役目が終わる書類ではありません。請求と支払いの根拠として、一定期間は取り出せる状態で残す必要があります。
保存の年数については、法人か個人事業か、青色か白色か、どの税目の話かによって扱いが変わり、電子データで受け取ったものと紙で受け取ったものでも要件が違います。この記事で年数を断定することは避けます。自社がどの区分に当たるのか、稼働報告書が保存対象の証憑に含まれるのかは、国税庁の案内を確認するか、顧問税理士に確認してください。インボイス制度のもとで請求書の記載事項がどうなるか、その付属資料である稼働報告書に何が求められるかも同様です。制度の運用は更新されるため、書式を設計した時点の理解のまま数年運用し続けるのは危険です。
電子でやり取りした場合の扱いについては、次のような案内が出ています。
電子取引を行った場合には、その取引情報に係る電磁的記録を、一定の要件の下で保存する必要があります。 出典: www.nta.go.jp
メールに添付されたPDFで報告書を受け取っている場合、それを紙に印刷して保管すれば足りるのか、電子のまま保存する必要があるのかは、確認しておいたほうがよい論点です。ここを曖昧にしたまま、担当者の受信箱の中だけに数年分が溜まっている会社は少なくありません。担当者が退職した時点で取り出せなくなります。
実務として決めておきたいのは、次の3点です。1つ目は保管場所を1か所に決めること。担当者のメール、共有ドライブ、経理のファイルサーバに分散していると、必要になったときに全部を探すことになります。2つ目は命名規則を決めること。「案件名_対象年月_氏名」のような形で統一しておくと、後から機械的に探せます。日付の書き方が人によって違うだけで、並べ替えが効かなくなります。3つ目は、承認の記録も一緒に残すことです。報告書のファイルだけが残っていて承認の履歴が別の場所にあると、突合の作業が発生します。
保管の観点から見ると、報告書を作る道具の選び方も変わります。個人の端末の表計算ファイルで作ってメールで送る形は、作る側にとっては手軽ですが、組織として取り出せる状態を保つには弱い設計です。最初から共有された場所に記録が残り、承認の状態もその場所で変わる形にしておけば、保管は運用の副産物になります。別途アーカイブする作業が要らなくなるという意味です。データの扱いや権限の考え方については安全性の考え方にまとめられているので、社外の人が関わる記録を置く場合は、権限の区切り方を先に確認しておくと判断が早くなります。
書き方でつまずくところ
書式と運用を決めても、実際に回し始めると同じ場所でつまずきます。よく出るものを3つ挙げます。
作業内容の粒度が人によって違う
同じ書式を配っても、書く量は人によって5倍から10倍違います。丁寧な人は1日8行書き、そうでない人は「開発」の2文字で済ませます。これは性格の問題ではなく、基準が示されていないことから起きます。
対処は、良い記載例を書式のシートに埋め込んでおくことです。空欄のテンプレートを配ると、各自が想像で埋めます。1行目にサンプルとして「例：会員登録画面の入力チェック実装、テストケース6件作成」と入れておくだけで、粒度は揃い始めます。差し戻すより、先に例を見せたほうが早く収束します。
もうひとつは、書く欄を狭くすることです。1セルに入る文字数を制限すると、長く書く人は自然に要点だけを書くようになります。逆に自由記述の大きな枠を与えると、書く人と書かない人の差が広がります。
月末にまとめて思い出しながら書いている
これが最も精度を落とします。20営業日前の作業を正確に思い出せる人はいません。結果として、それらしい内容が並んだ報告書ができあがり、詰められたときに答えられなくなります。
日々の記録がどこかに残っている状態を先に作ることが、唯一の対処です。ただし、日報を新しく書かせるのは負担が増えるだけです。すでに何かを更新しているなら、そこから拾えるようにするほうが現実的です。タスクの状態を動かしているなら動かした履歴が、チャットで報告しているならその投稿が、記録の素材になります。素材があれば、月末の作業は「思い出す」ではなく「まとめる」に変わります。この差は体感で3倍から5倍の時間差になります。
報告書を書く時間そのものが揉める
時間で払う契約では、報告書の作成時間を稼働に含めるかどうかが論点になります。含めないと決めるなら、その分だけ実質単価が下がることを双方が理解している必要があります。含めると決めるなら、月にどのくらいまでを想定するかを合意しておきます。
この論点を放置すると、報告書の粒度を上げる要求が出るたびに小さな不満が積もります。書く手間を増やす変更をするときは、それが何分増えるのかをセットで話すと、話が具体的になります。逆に言えば、書式を軽くする改善は、単価を上げずに受け手の実質報酬を上げる施策になります。
表計算ファイルとチャットで回したときに起きること
多くのチームは、稼働報告書を表計算ファイルのテンプレートで配り、メールかチャットで回収しています。3人くらいまではこれで十分回ります。人数が増えると、いくつかの問題が同時に出ます。
まず、版が増えます。テンプレートを更新しても、手元に古い版を保存している人がいます。列が1つ違うファイルが返ってきて、集計時に手作業で直すことになります。「最新版はこれです」というメッセージを毎月流している時点で、その運用は限界に近づいています。
次に、提出されたかどうかが一覧で見えません。受信箱を上から読み、誰から届いていないかを頭の中で消し込む作業が発生します。10人を超えたあたりから、この確認だけで毎月30分以上かかるようになります。しかもこの作業は誰の成果物にもならず、記録にも残りません。
3つ目は、承認の状態が書類の外にあることです。ファイルには承認欄があっても、実際に承認したかどうかはメールの返信の中にしかありません。3か月後に「あの月は承認したのか」を調べるには、メールを検索することになります。担当者が変わっていれば、その受信箱にはもう入れません。
4つ目は、同時に触れないことです。1人がファイルを開いて編集している間、他の人は編集できません。月末の締めの時間帯に集計担当がファイルを開きっぱなしにしていると、提出しようとした人が待たされます。共有の表計算サービスを使えばこの問題は減りますが、今度は誰がどこを書き換えたのかが追いにくくなります。
こうした詰まりは、書式の工夫では解決しません。書類を「ファイル」として扱っている限り、版と場所と状態の3つが常にばらけます。稼働の記録を、ファイルではなく状態を持つカードとして扱う発想に切り替えると、この3つは同時に片づきます。
稼働の記録を板の上に置くという考え方
ボード型のタスク管理ツールを稼働報告に使う場合、考え方は単純です。案件ごとに板を1枚持ち、作業をカードにし、カードの列で状態を表す。稼働の記録はカードに紐づけて残し、月末はそれを集計するだけにします。
この形の利点は3つあります。1つ目は、日々の作業がそのまま素材になることです。カードを動かした履歴が残るため、月末に思い出す作業が減ります。2つ目は、提出と承認の状態が列で見えることです。「提出済み」「承認済み」「差し戻し」という列を作れば、誰の分がどこで止まっているかが一目で分かります。督促の対象を探す時間がなくなります。3つ目は、記録が個人の端末に散らないことです。板の上にあるものは、担当者が変わっても残ります。
どこまでできるかは道具によって差があるため、できることで機能の範囲を確認してから運用を設計するのが順序として正しくなります。板の数や参加できる人数の区切り方は費用に直結するので、料金で区切りの考え方も先に見ておくと、案件が増えたときの見通しが立ちます。
一方で、ボード型が向かない使い方もはっきりしています。稼働時間の計測そのものを自動で行いたい場合、つまり画面の操作時間を取得して自動で集計したいような要件は、専用の勤怠管理や工数管理の仕組みのほうが適しています。ボード型のタスク管理は、あくまで人が状態を動かす道具です。自動化と外部連携を軸に組み立てたい場合も、そちらに強い道具を選んだほうが素直です。ここは正直に線を引いたほうが、導入したあとで後悔しません。
すでに別の道具で板を運用しているなら、乗り換えの前に移行の可否を確認しておく必要があります。Trelloからの移行には取り込みの手順がまとまっていますが、自動で取り込めるのはTrelloからだけで、他の道具からは手作業になります。稼働報告のような毎月動く運用では、移行の手間が現場の負担として直に効くため、ここを軽く見積もると定着しません。
道具を選ぶときの比較の材料
稼働報告の運用を道具に載せる場合、比較の論点は機能の多さではなく、人数と権限と料金の区切り方に集まります。比較ページを横に並べると、その傾向がはっきり出ます。
Trelloとの比較は、ボードの操作感には満足していて、人数が増えたときの費用や制限で行き詰まった人が読む組み合わせです。稼働報告の運用では、社外の作業者を招待する場面が必ず出るため、招待するたびに費用が積み上がる構造かどうかは早い段階で確認する価値があります。Asanaとの比較とmonday.comとの比較は、設定できることの多さと、全員が使いこなせるかの落差が論点になります。設定項目が多い道具は、設定する人の負担がそのまま増えます。報告の手間を下げるために入れた道具で、覚えることが増えては本末転倒です。
Notionとの比較は性質が違います。自由度が高く、報告書の書式そのものを自分たちで組めます。設計できるチームには強力ですが、設計した人が抜けると維持されなくなる弱さがあります。稼働報告のように毎月確実に回さないといけない運用では、この属人化は無視できません。Backlogとの比較とJootoとの比較は、日本語で作られていることを前提に選ばれてきた道具との比較で、論点は料金の区切り方と権限の細かさに寄ります。全体の並びを見たい場合は比較の一覧から入ると、どの軸で迷っているのかを整理しやすくなります。
料金の区切り方は、稼働報告の運用では特に効きます。機能で絞らず、区切るのは人数とボードの数だけという設計であれば、外部の作業者を招待したときに「この機能はこのプランから」という判断が発生しません。報告してもらう側が、相手に見せられる機能の範囲を気にせずに済むという意味でもあります。逆に機能でプランが分かれる仕組みでは、承認のワークフローや権限の細かい設定が上位プランに寄っていることがあり、稼働報告の運用に必要な機能が下位プランで足りるかを事前に確認する必要が出ます。
同時に、持っていないものも先に把握しておいたほうが選定は早く終わります。ソースコードを置くリポジトリ機能は持たないこと、自動化と外部連携では勝負しないこと、画面は日本語のみであること、自動で取り込めるのはTrelloからだけであること。開発チームがコードと課題を1か所に置きたい場合や、勤怠システムと自動連携させて工数を流し込みたい場合は、この時点で候補から外れます。判断に迷う点はよくある質問に集まっているので、選定の前に一度目を通しておくと、後戻りが減ります。
なお、料金や上限の数値は各社とも改定されるため、比較の際は必ず公式の料金ページで、いつ時点の情報か、税抜か税込かを確かめてください。記事や比較サイトの数字をそのまま社内の稟議に載せると、金額がずれた状態で承認を通すことになります。
最後に、稼働報告書の書き方で最も効く改善を1つ挙げるなら、書式を整えることではありません。日々の作業が自然に記録として残る場所を先に作り、月末はそれをまとめるだけの作業に変えることです。書式は差し戻しを減らす道具であり、記録の質を上げる道具ではありません。記録の質は、書くタイミングが作業の直後かどうかで決まります。月末に思い出して書いている限り、どんなに整った書式でも、そこに入る内容は記憶の再構成にとどまります。請求の根拠として通用する報告書は、書式の完成度ではなく、記録が残る仕組みから生まれます。
Q1. 稼働報告書に決まった様式はありますか？
法律で定められた様式はありません。契約の当事者どうしが合意した書式を使います。ただし請求の根拠として使うなら、対象期間、案件名、日別の稼働時間と合計、作業内容、承認者名と承認日は最低限入れてください。この5つが揃っていれば、後から第三者が見ても支払いの妥当性を判断できます。
Q2. 稼働時間の丸め方はどう決めればよいですか？
書式を配る前に決めて、契約書か覚書に明記してください。15分単位で切り捨てるのか、分単位でそのまま積むのかで、20営業日分では1時間以上の差が出ます。決めていないと作成者ごとに扱いが変わり、合計が合わなくなります。単価が高い契約ほど、この差は金額として無視できません。
Q3. 稼働報告書はどのくらい保管する必要がありますか？
保存年数は、法人か個人事業か、どの税目の話か、電子か紙かで扱いが変わるため、この場では断定できません。国税庁の案内を確認するか、顧問税理士に確認してください。実務としては、担当者のメール内ではなく、命名規則を決めた共有の保管場所に、承認の記録とセットで残す形にしておくと安全です。
Q4. 承認者は誰にすればよいですか？
その稼働内容が契約の範囲内かどうかを判断できる人、多くの場合は日々やり取りしている現場の責任者です。金額の妥当性は経理が確認する形にして、内容の承認と金額の確認を直列で分けると滞りません。合議にすると誰も最終判断をせず、月末に数営業日を失います。代理承認者も先に決めておいてください。