源泉徴収票300枚、
スプレッドシート1つに

ボトルネックは計算ではなく、集計です

日本の年末調整は、計算上は決定論的です。従業員の課税所得は、総支給額から法定の給与所得控除、社会保険料、配偶者控除・扶養控除、生命保険料控除・地震保険料控除を差し引き、源泉徴収税額表を適用し、年間の源泉徴収額と比較して、12月の給与で過不足を精算します。市場にあるどの給与計算プラットフォームでも、この計算は実行できます。

しかし、どのプラットフォームも、毎年1月に人事部長の机に届く次の質問には答えられません。「日本拠点の全従業員の年間報酬サマリーを、英語で、Excelで、金曜日までに送ってください。」

この質問に答えるには、各従業員の源泉徴収票を開く必要があります。これは、総支給額、給与所得控除後の金額、所得控除の額の合計額、源泉徴収税額、社会保険料等の金額など26の定義済みフィールドを含む、情報が詰まった1ページのPDFです。そして、該当する数値を手作業でスプレッドシートに、一人ずつ入力していきます。300人の従業員がいる会社の場合、300枚のPDF、約1,500のデータポイントを転記することになり、タイピング速度と同時に開けるPDFビューアの数にもよりますが、6時間から15時間のデータ入力作業が必要になります。

計算は無料でした。転記こそが、1月の最初の1週間を費やす原因なのです。

給与ソフトの限界：システム間連携の現実

日本の給与プラットフォームはデータをエクスポートできます。弥生給与は集計表からCSVを出力し、e-Tax CSV形式にも対応。freee人事労務（約38万事業所が利用するマーケットリーダー）は源泉徴収票を生成し、年末調整データのエクスポートも可能。SmartHRは源泉徴収票の取込形式として、CSV（SmartHR形式）、PDF、CSV（eLTAX形式）の3つに対応。マネーフォワード クラウド給与は勤怠から税務申告まで一貫して処理します。全従業員が入社時から同じ給与システムを利用し、すべての報告関係者が日本語を読めるのであれば、エクスポートの道は存在します。

しかし、以下の3つの現実が、その道をカタログ記載よりも困難にしています。

PDFのみの壁は現実的かつ広範囲に及ぶ。 従業員301～1,000人の製造業のユーザーがSmartHRのアプリマーケットに投稿したレビューが、問題を正確に描写しています。freee人事労務は源泉徴収票データをPDFでのみ出力 — 提供されるCSVエクスポートは年末調整確認用であり、構造化された源泉徴収票データではありません。SmartHRに取り込むため、人事チームは約560人分の従業員について、各PDFに従業員IDと氏名を手動で命名・保存し、1ファイルずつ個別にアップロードする必要がありました。“導入初回の昨年度は源泉徴収票連携作業に時間を要したため、例年より公開が遅れた経緯がございます” — 移行初年度は、証明書連携作業に時間がかかり、従業員への公開が例年より遅れました。日本の活発な給与ソフト移行サイクル全体で考えると、この手作業は人時間ではなく、人週単位で計測されます。

年度途中の給与システム移行でデータが分断される。 例えば、7月にアウトソース先の給与システム（弥生給与）からSmartHRに切り替えた企業では、従業員の源泉徴収票データが2つのシステムにまたがってしまう。CSVのフォーマットは異なり、カラム名は日本語。文字コードもShift-JIS（弥生）とUTF-8（モダンなクラウドプラットフォーム）で異なる。2つのシステムのエクスポートデータを1つのグローバルレポートに統合するには、翻訳者、データクレンジング用スクリプト、そして人事チームが想定していた以上のスプレッドシート操作が必要になる。

グローバル本社は日本語を読めない。 外資系企業の日本法人では、シンガポール、ロンドン、ニューヨークなど地域本社への月次・四半期レポートに、日本従業員のデータを英語で提出する必要がある。カラムは「年間総支給額」「源泉徴収税額」「社会保険料」などだ。弥生給与のCSVエクスポートでは「支払金額」「源泉徴収税額」「社会保険料等の金額」とラベル付けされているため、毎回手作業で翻訳・フォーマットしなければならない。データ自体は存在する。しかし、PDFに閉じ込められ、レポートを受け取る側が読めない言語でラベル付けされているのだ。

証明書300件も一括アップロード：バッチ抽出で作業のギャップを埋める

バッチ処理とは、複数の書類を一度にアップロードし、定義したフィールドごとに1行・1列でまとめた単一の出力ファイルを受け取る方法です。これにより、PDF300件を1件ずつ開いて転記して閉じて繰り返す作業と、300件すべてを1回の操作で処理するのとでは大きな差が生まれます。

このワークフローでは、転記作業を「指示」に置き換えます：

ステップ1：列を一度だけ定義する。 各証明書のデータを手入力する代わりに、抽出したい項目を定義します。ここでは列名による抽出を使用します。「従業員名」「給与総額（円）」「源泉徴収税額（円）」「社会保険料合計（円）」などのフィールド名を入力するだけで、AIが各書類を読み取り、値の意味を理解して該当箇所を特定・抽出します。ページ上の位置ではなく意味で判断するため、給与ソフトごとに源泉徴収票の形式が異なっても問題ありません。弥生は法人番号をある場所に、SmartHRは別の場所に配置し、小規模会計事務所の紙の証明書はさらに異なるレイアウトです。列名による抽出は、座標ではなく意味ラベルを読み取ります。

標準的な源泉徴収票のバッチ抽出では、以下の8列でグローバル人事・財務チームに必要なフィールドをカバーできます：

報告の拡大に応じて、生命保険料控除、地震保険料控除、住宅借入金等特別控除、扶養人数、配偶者控除の詳細などのカラムを追加できます。再トレーニングや給与計算事業者ごとのテンプレートは不要です。カラム名を追加するだけでAIが値を抽出します。源泉徴収票の全26項目の詳細な解説と単一証明書の抽出ワークフローについては、源泉徴収票をExcelに抽出するガイドをご覧ください。

ステップ2：すべてを一括アップロード。源泉徴収票のファイル（給与計算ソフトのPDF、前職の紙の証明書のスキャン、印刷物の写真など）を1つのアップロード領域にドラッグしてください。ツールがそれらを1つのセッションでまとめて処理します。1ページあたり5～10秒で、手動入力の平均3分と比べて約18倍高速ですが、本当の効率化は300もの個別ファイルを開いて転記して閉じる手間が省ける点にあります。

ステップ3：確認してエクスポート。抽出が完了すると、プレビューテーブルが表示されます。これは、従業員ごとに1行、定義した列で構成された300行のテーブルです。元のPDFと照らし合わせていくつかの行を確認し（ランダムな15名の従業員を5％スポットチェックすれば、ほとんどの抽出問題を発見できます）、プレビュー上で直接修正して、Excel（XLSX）またはCSVとしてエクスポートします。ファイルはすぐにグローバルHRISへのアップロード、外部の会計士への転送、または法定報告サマリーテーブルの準備に使用できます。

処理の前に従業員から証明書を収集する必要がある企業（例えば、前職から紙ベースの源泉徴収票しか持っていない従業員がいる場合）には、収集リンクが入力を簡素化します。共有可能なURLを生成し（受信者の登録は不要）、各従業員に送信すると、アップロードされたファイルが直接処理キューに届き、バッチ抽出の準備が整います。

個人の源泉徴収票から法定調書合計表へ：誰も予算を組まない税務署の締切

日本で給与を支払うすべての事業主は、年末調整に関して2種類の書類を提出する必要があります。税務署への源泉徴収票と、各従業員の市区町村への給与支払報告書です。これらをまとめる書類が法定調書合計表（給与所得の源泉徴収票等の法定調書合計表）であり、すべての個人票の合計を集計し、個人票とともに1月31日までに提出しなければなりません。

2016年以降、eLTAX（電子提出の一元化）により、事業主はPCdeskで統一CSVレイアウトを使用し、市区町村への給与支払報告書と税務署への源泉徴収票を一度の操作で作成・提出できるようになりました。これにより、同じデータを2回準備して送付する必要がなくなりましたが、eLTAXに取り込む前に、データが構造化された機械可読形式で存在している必要があります。

電子申告義務は強化されています。現行ルールでは、前年に法定調書を100枚以上提出した事業主は、e-Taxまたは光ディスクによる電子申告が義務付けられています。2027年1月からは、その基準が30枚に引き下げられます。つまり、従業員が30人程度の会社でも、義務化の対象となります。実質的な対応期間は今です。今年準備する2025年分のデータが、基準引き下げ時に電子申告が必要かどうかを左右します。

大企業向けには、TKCのe-TAX法定調書システムのようなソリューションが、給与システムからのCSVインポート、一括電子署名、eLTAXとe-Taxへの一括提出、コンプライアンス記録の保存まで、電子申告の全ワークフローを処理します。これらのツールは申告の問題を解決しますが、退職社員の紙の証明書、前職のPDF、旧給与システムのエクスポートから、これらの申告ツールが求める構造化CSVにデータを変換する上流の問題は解決しません。一括抽出はその上流のギャップを埋めます。源泉徴収票が、その起源を問わず、すべて同じスプレッドシートに集約されれば、法定調書合計表の作成は、列の合計とカテゴリ別の集計の問題となり、60枚のPDFを給与台帳と照合する手間は不要になります。

従業員が3つの異なる給与計算システムにまたがる場合

バッチ処理における最も一般的な課題は、データ量そのものではありません。それは、そのデータ量を生み出すソースの多様性です。毎年1月に繰り返される3つのシナリオをご紹介します。

年度途中の給与システム移行。8月に弥生給与からSmartHRに移行した企業では、6ヶ月分のデータが一方のシステムに、残り6ヶ月分がもう一方のシステムに存在します。弥生システムは1月から7月分の源泉徴収票を生成し、SmartHRは8月から12月分を発行します。従業員の個人の税務記録としては、この2つの証明書を合わせて1年分となります。グローバル報酬レポートでは、1人の従業員が2つのソースシステムと2つの文書形式にまたがることになります。バッチ抽出では、同じアップロード内で両方のPDFを処理し、「従業員名」が両方で一致し、出力行には結合された抽出データが反映されます。

年度途中入社で前職がある場合。日本の所得税法では、年度途中に入社するすべての従業員は、年末調整のために前職の源泉徴収票を提出する必要があります。新しい雇用主は前職の所得を源泉徴収計算に含め、その後、1年分の単一の統合証明書を発行します。しかし、現在の雇用主と前職の雇用主のデータを分離する必要がある分析（報酬ベンチマーク、コストセンター別予算配分、駐在員の税額調整など）では、両方の証明書がスプレッドシートに必要です。抽出テーブルの「雇用主名」列により、どの行がどのソースに属するかがすぐに識別できます。

合併後の統合処理。2社が合併。存続会社の従業員の給与履歴は、2つの異なるシステム、場合によっては2つの異なる給与プロバイダー、2つの異なる形式、給付金や手当のための2つの異なる勘定科目マッピングに分散しています。合併後の最初の税年度に、これらすべての従業員が同一の法定調書合計表に初めて記載されます。互換性のない2つの給与システムのエクスポートを調整しようとする代わりに、PDFからの一括抽出により、発生元に関係なく、1つのスキーマを持つ1つのテーブルを、ユーザーが定義して取得できます。

よくある質問

スキャンした紙の証明書とデジタルPDFでは、どう違いますか？

抽出エンジンは、スキャン画像、スマートフォン写真、ネイティブPDFを同様に処理します。200 DPI以上の鮮明なスキャンであれば、印字されたテキストは最大99%の精度で抽出されます。手書きの証明書や、照明が不十分な低解像度のスマートフォン写真では精度が低下します。収集リンクを通じて従業員が紙の証明書を提出する場合、「平らな面、良好な照明、文書全体がフレーム内」という簡単な品質ガイドラインに従うことで、アップロード前のほとんどの問題を防げます。

freeeのCSVエクスポートだけではダメですか？

freee人事のCSVエクスポートは年末調整データの確認用であり、構造化された源泉徴収票データの出力には対応していません。そのため、他のシステムにインポート可能な形式で源泉徴収票の全項目を出力することはできません。実際にfreeeからSmartHRへ移行した企業では、CSVエクスポートに源泉徴収票のデータ構造が含まれていないため、個別のPDFを手動で処理する必要があったとの報告があります。freee内で完結し、freeeの標準レポートで十分な場合はCSVエクスポートでも問題ありません。しかし、他のシステムや他言語でのデータ利用、他社の証明書と統合する必要がある場合は、PDFからの一括抽出が現実的な方法です。

バッチ抽出の出力はe-TaxやeLTAXのCSVインポートに対応していますか？

バッチ抽出では、指定したカラムで整ったExcelまたはCSVファイルを出力します。これは、政府が定めたフィールド順序とエンコード仕様を持つeLTAX統一CSVレイアウトの直接的な代替品ではありません。しかし、すべての従業員データが1つの構造化されたスプレッドシートにあれば、公式CSVテンプレートへの入力は単純なマッピング作業になります。英語のカラムヘッダーを統一CSV形式に必要な日本語フィールドに一度マッピングし、そのマッピングを全行に適用するだけです。これは、各PDFから個別にデータを抽出し、手作業で公式形式に入力するよりも格段に高速です。

退職所得の源泉徴収票について

退職所得の源泉徴収票は、異なる様式と項目を使用します。課税額の計算は、（支払額 − 勤続年数に応じた控除額（20年までは1年あたり40万円、以降は1年あたり70万円））× 1/2 です。これらは、「退職金支払額」「勤続年数」「退職所得控除額」「源泉徴収税額」という独自の列定義を持つ別のバッチとして処理する必要があります。抽出方法は同じですが、列名が異なります。年間に多くの退職者を処理する企業では、通常の給与所得バッチと並行して退職所得バッチを実行することで、両方のワークフローを整理できます。

バッチ抽出でマイナンバー（個人番号）データは扱われますか？

いいえ。人事チームが通常扱う従業員控除用の源泉徴収票では、マイナンバー欄は空白またはマスクされています。マスクされていないマイナンバーは、法令遵守のために別途保管される事業者控除用の写しにのみ表示されます。従業員控除用の写しを対象とするバッチ抽出処理では、マイナンバーデータに触れることはありません。

300行の精度を確認するには？

バッチ抽出におけるコスト効率の良い検証方法：ランダムに5%（300行中15行）をサンプリングし、各抽出フィールドを元のPDFと比較します。サンプル全体で精度が高ければ、バッチは信頼できます。系統的なエラー（例：SmartHR発行の証明書から社会保険料の合計が一貫して正しく抽出されない場合）が見つかった場合は、カラム名をより正確な日本語のフィールドラベル（単なる「Social Insurance」ではなく社会保険料等の金額）に修正して再実行します。カラム定義は将来のバッチ実行でも再利用可能なため、この検証への投資は毎年1月に効果を発揮します。

給与計算はシステムがやってくれる。最後の1マイルはスプレッドシートだ。

日本の給与計算ソフトのエコシステムは、計算問題をすでに解決している。弥生給与、freee人事、SmartHR、マネーフォワードは、いずれも国税庁の要件を満たす正確さで源泉徴収、社会保険料、年末調整を計算する。ギャップは計算ではなく、データの移行にある。毎年1月、日本中の人事チームは、給与分析でも、予算計画でも、従業員相談でもなく、PDFからスプレッドシートへの数字の転記に最初の営業週間を費やしている。

数字を積み上げてみよう。1枚3分の証明書が300枚で15時間。グローバル本社向けの英語版でも同じ作業。新しい給与システムへのデータ移行でも同じ。法定調書合計表の集計でも同じ。計算は無料だったが、転記作業は毎年、人事部門の累計1ヶ月分の労力を消費している。

バッチ抽出は給与計算ソフトを置き換えるものではない。ソフトが終わったところから始めるのだ。1回のアップロード、1つのスプレッドシート、そして1月にPDFを開いて数字を打ち込む1週間が不要になる。

サンプル証明書でバッチ抽出を試す