タイムスタンプ付きPDFでも記載要件チェックは別— 電帳法と混同しない見方

1. 二つのレーンを分ける

1-1. 電帳法レーン：保存の要件

電子取引データの保存、スキャナ保存、検索要件、真実性の確保などが論点です。
タイムスタンプは、その手段の一つとして使われることがあります。
詳細はスキャナ保存や社内の電帳法マニュアルを参照します。

1-2. インボイスレーン：記載と登録の要件

登録番号の形式・公表照合、取引内容、税率ごとの対価の額と税額などが論点です。
手順はチェック手順、項目は記載要件チェックリストです。
タイムスタンプの有無では、これらの合否は決まりません。

2. 混同が生む具体的な穴

2-1. タイムスタンプはあるが登録番号がない

保存としては整って見えても、適格請求書の記載としては足りないことがあります。
受取側は電帳法のチェックリストとインボイスのチェックリストを別紙にします。

2-2. インボイスはPASSだが検索要件が足りない

逆に、記載は揃っていても、ファイル名や索引が社内ルールに合わず電帳法側で要対応、というケースもあります。
保存期間の整理は保存期間もあわせて確認します。

2-3. 経過措置・特例と電帳法を同時に省略する

「少額だから」「免税事業者だから」と両方の確認を飛ばすと、説明不能になります。
少額特例や経過措置はインボイス側の例外レーンであり、電帳法の保存義務を自動免除するわけではありません。

3. 具体シナリオ：スタンプ付きPDFを新人に渡す

システム部が「このPDFはタイムスタンプ済みなので保管して」と経理に渡しました。
新人は保管フォルダに入れただけで、登録番号の公表照合をしませんでした。
月末に税率区分の記載欠けが発覚し、差し戻しが発生しました。
受け渡しチェックリストに「電帳法：済／インボイス：未」の二欄を置くと再発しにくいです。

不備の影響は不備と控除リスクを参照します。
インカク（incaku） はインボイスレーン（形式・公表・記載）の自動化に使い、電帳法のタイムスタンプ付与は別システムで担う分担が明確です。

4. 二レーン・チェックリスト

• 電帳法：真実性・可視性・検索など、社内規程どおりか
• インボイス：登録番号・公表・記載要件を別途確認したか
• タイムスタンプ有無でインボイス合否を決めていないか
• 特例・経過措置を電帳法免除と混同していないか
• 差し戻しは記載欠けを具体的に書いたか
• 簡易インボイスなら簡易の要件で見ているか

5. よくある質問

Q. タイムスタンプがあれば改ざんされていないので控除できますか

改ざん防止の手がかりにはなっても、記載要件の充足とは別です。
控除判断に必要な確認は依然として残ります。

Q. 紙の請求書をスキャンしてタイムスタンプを付ければ十分ですか

スキャナ保存の要件と、インボイス記載の確認の両方が必要です。
スキャン品質で文字が読めなければ、どちらも不合格になり得ます。

Q. 電子インボイスならタイムスタンプは不要ですか

方式や社内規程によります。
「不要だからインボイス確認も不要」にはなりません。

Q. チェックを一本化したい場合は

UI上は1画面でも、内部ステータスは「電帳法」「インボイス」を分けて持つ方が事故が減ります。
一本の「OK」ボタンだけにすると、どちらのOKか分からなくなります。

7. 二レーン運用の画面設計と引き継ぎ

7-1. ステータス二欄の例

電帳法: 未／対応中／済
インボイス: 未／WARN／PASS／FAIL
「総合OK」は両方済のときだけ自動表示にします。
片方だけ済みなのに総合OKが出ると、研修しても事故が再発します。

7-2. システム部と経理の境界

タイムスタンプ付与や保管フォルダ設計はシステム部が主導しがちです。
登録番号照合と記載確認は経理が主導します。
受け渡し票に両欄を印刷し、相手レーンの未完了を見える化します。

7-3. 監査・税理士への説明資料

「タイムスタンプがあるので問題ない」だけでは説明として薄いです。
電帳法の保存要件をどう満たしたか、インボイスの記載・公表をどう確認したかを分けて書きます。
サンプル証憑を数件添付し、二レーンの記録が残っていることを示せると安心です。

新ツール導入時は、電帳法機能とインボイス機能のデモを同日に行い、混同ポイントをその場で潰します。
導入資料の見出しも「保存」と「記載確認」を分け、1つの「電子化で全部解決」スライドを避けます。
解決スライドは聞こえが良い一方で、現場の確認省略を誘発します。

8. まとめ

• 電帳法とインボイスは別レーン
• タイムスタンプは保存手段の一つ
• 記載・公表確認は別途必須
• 特例を両レーン免除と混同しない
• ステータスは二欄で持つ

9. 導入チェックリスト（電帳法×インボイス）

新システムを入れるときは、電帳法の要件対応表とインボイスの確認項目表を別紙で作ります。
同じ「電子化プロジェクト」資料に混ぜると、読んだ人が片方で十分だと誤解します。
プロジェクト完了条件も、両表の未達ゼロを必須にします。

パイロット運用では、タイムスタンプ済みだが記載欠けのサンプルを意図的に流し、検知できるか確認します。
検知できないなら、インボイスレーンが自動化・手順化されていません。
逆に、記載は足りるが検索要件不足のサンプルも流し、電帳法レーンの穴を見ます。

運用開始後3ヶ月は、総合OKの内訳（両レーン済の内訳）を週次でレビューします。
電帳法のみ済の滞留が多いなら、経理側の記載確認がボトルネックです。
インボイスのみ済の滞留が多いなら、保存・タイムスタンプ側の処理遅延です。

10. 今日から使える確認メモ

タイムスタンプ済みファイルを受け取ったら、電帳法欄を済にする前にインボイス欄が未でないか確認します。
未なら経理キューへ回し、保存完了だけでクローズしません。
逆にインボイスPASSでも、検索要件やファイル命名が社内ルール外なら電帳法欄を未のままにします。
両方を同じ日に終わらせる必要はなく、どちらが遅れているかを見える化することが大切です。
週次の滞留リストは、電帳法待ち／インボイス待ちでシートを分けます。
混ぜると担当が自分のレーン以外を気にして疲弊します。
パイロットで意図的に欠けサンプルを流す訓練は、半年に一度やり直すと効果的です。

補足

タイムスタンプは保存の手段であり、記載確認の完了印ではありません。
迷った案件は WARN に残し、週次で基準を揃える会議に持ち込みます。
持ち込みなしの個別判断が続くと、月によって厳しさが揺れます。

10. 電帳法×インボイス二レーンのパイロット設計

パイロットでは、タイムスタンプ済みだが記載欠けのサンプルを意図的に流し、検知できるか確認します。
検知できないなら、インボイスレーンが自動化・手順化されていません。
逆に、記載は足りるが検索要件不足のサンプルも流し、電帳法レーンの穴を見ます。

画面のステータスは電帳法（未／対応中／済）とインボイス（未／WARN／PASS／FAIL）の二欄にします。
「総合OK」は両方済のときだけ自動表示にします。
片方だけ済みなのに総合OKが出ると、研修しても事故が再発します。

システム部と経理の境界は、タイムスタンプ・保管設計をシステム、登録番号照合・記載確認を経理、とします。
受け渡し票に両欄を印刷し、相手レーンの未完了を見える化します。
導入資料の見出しも「保存」と「記載確認」を分け、「電子化で全部解決」スライドを避けます。

運用開始後3ヶ月は、総合OKの内訳を週次でレビューします。
電帳法のみ済の滞留が多いなら経理側の記載確認がボトルネック、インボイスのみ済の滞留が多いなら保存側の遅延です。
滞留の偏りが見えれば、増員や手順改善の優先順位が決まります。

注意

本記事は国税庁の公表資料等に基づく一般的な情報の整理であり、税務・法的助言ではありません。
個別の判断は税理士等の専門家にご確認ください。