60枚のフランスの給与明細書、
1つのスプレッドシートへ
Silaeは月間700万枚以上の給与明細書(ブルトン・ド・ペ)を処理しています。すべての社会保険料を計算し、すべての協約(コンベンション・コレクティブ)を適用し、フランスの雇用主が毎月URSSAF、CNAV、CPAM、France Travailに提出するDSN(名目社会保険申告)ファイルを生成します(2016年5月20日付政令第2016-611号に基づく)。しかし、それらの60枚の給与明細書を1つのスプレッドシートに統合することはできません。PayFitもSage Paieも同様です。DSN送信を可能にする従業員ごとのPDF構造こそが、毎月60の個別ファイル、年末には720ものファイルを人事担当者に残す原因なのです。
重要ポイント
- 年間36時間 — 従業員60名のフランス企業が、機械生成されたPDFから給与ソフトが出力を拒否するスプレッドシートへ給与データを転記するのに費やす時間。
- Silaeで調整されたテンプレートがPayFitでは機能しない理由は、労働法典が16の必須項目を定めているものの、その配置を指定していないためです。3つの準拠した給与プラットフォームが、互換性のない3つのPDFレイアウトを生成します。
- 毎月の給与データが1つの構造化されたテーブルにあれば、DSNのクロスチェックは数秒で完了し、退職する従業員の報酬履歴も、12ヶ月分のPDFを何日もかけて探す代わりに、1回のクエリで把握できます。
なぜフランスの給与システムは1つのスプレッドシートではなく、個別のファイルを出力するのか
2017年1月以降、すべての民間企業に義務化されたDSNは、従業員ごとに個別のレコードブロックを持つ月次電子ファイルです。Santé、Retraite、Famille、Chômage、CSG/CRDSといったすべての保険料明細は、従業員ごと、月ごとに送信されます。給与ソフトウェアの主要な出力はスプレッドシートではありません。それはnet-entreprises.frで検証を通過するDSNファイルです。各従業員が受け取るPDFの給与明細書は、そのコンプライアンスワークフローの副産物であり、労働法典第R3243-1条に基づく法的文書として、明細書あたり16の必須項目が定められています。
この構造にはギャップがあります。DSNは従業員ごとの個別レコードを必要とし、給与ソフトウェアは従業員ごとに個別のPDFを生成します。しかし、人事、経理、そして会計士(expert-comptable)は、統合されたビューを必要とします。部門別の総給与(salaire brut)、月間の総事業主負担(cotisations patronales)、送信前にDSN合計と照合するための単一の表です。社内の月末レポートはすべて同じ方法で始まります。60のPDFを開き、それぞれから同じ16のフィールドを見つけ出し、その数字をスプレッドシートに入力するのです。
1枚の明細書あたり3分(これは控えめな見積もりで、課税対象純額(net imposable)と手取り額(net à payer)の区別、CSGの基準が総給与の98.25%であることの確認、および前払い保険料項目の確認を含みます)とすると、60人の従業員がいる企業は、データ転送だけで毎月3時間を費やします。12回の給与サイクルで36時間です。そして、これはDSNの照合を試みる前の話です。
フランス市場の主要な3つの給与プラットフォーム、Silae、PayFit、Sage Paieは、同じ法的テンプレートから構造的に異なるPDFを生成します。毎月700万枚以上の明細書を処理し、会計事務所(cabinets d'expertise comptable)で支配的なSilaeは、左上に事業主情報、右上に従業員情報、本文にリスクカテゴリ別にグループ化された保険料、フッターに年間累計を配置したマルチブロックレイアウトを採用しています。給与を内製化する中小企業向けに構築されたPayFitは、同じ情報をプログレッシブディスクロージャーを備えたモダンなシングルカラムレイアウトで配置します。Sage Paieはより伝統的な会計形式に従います。3つすべてが第R3243-1条に準拠していますが、プロバイダー間でフィールドの位置を標準化しているものはありません。Silaeの出力に合わせて調整されたテンプレートベースの抽出ツールは、PayFitのPDFを読み取ることができません。また、年度途中で給与プロバイダーを変更した企業は、同じ会計年度内に同じ従業員に対して、構造的に異なる2つのPDF形式を持つことになります。
1人の従業員が1行とは限らない — バッチ抽出を崩す契約形態と役職区分
1枚の給与明細(ブルトン・ドゥ・ペ)は、1人の従業員の1ヶ月分のスナップショットです。これを60人に拡大する場合、個別処理では無視できる構造上の違いを抽出ツールが処理する必要があります。最初の違いは、60行すべてが同じ拠出金構造ではないことです。
カードルと非カードル。 2019年に旧2制度が統合されたAGIRC-ARRCO制度(全民間部門従業員を対象とする強制補完年金制度)では、拠出率はカードルと非カードルで技術的に同一です。しかし、カードル区分は追加拠出金、すなわちApec(カードル雇用協会)拠出金(従業員負担0.024%、雇用主負担0.036%)を発生させます。この項目はカードルの給与明細に表示され、非カードルには表示されません。60行すべてに固定の控除列セットを定義するバッチ抽出では、1~15行目(カードル)にApec控除があり、16~60行目(非カードル)にはないという事実を、後続の列をずらさずに処理する必要があります。
CDI、CDD、および派遣。 正社員(CDI — 無期雇用契約)と有期社員(CDD — 有期雇用契約)は、同じ16の必須項目を持つ給与明細を生成します。しかし、CDDには追加の契約終了時支払い、すなわち不安定手当(契約期間中に支払われた総報酬の10%に相当、労働法典第L1243-8条に基づく)があります。この手当は最終給与明細に別項目として表示され、それ以前の月やCDIの明細にはありません。派遣社員(派遣労働者)は、派遣元企業(ETT)から給与明細を受け取りますが、ユーザー企業の人事部門が人件費データを統合する場合、これらの派遣明細も同じスプレッドシートに入力する必要があります。
従業員間の変動手当。 基本給が同じ2人の従業員でも、変動報酬要素により実質的に異なる給与明細が生じることがあります。勤続手当(多くの業種別協約で義務付け)、業績手当、休暇手当(シンテックなど一部業種で義務付け)、交通費、食事券(通常50~60%を雇用主が負担)などです。各手当は報酬ブロック内で独自の行を占めます。「基本給」と「総支給額」を別々の列として含むバッチ列定義では、両者の差(すべての付加給与の合計)が従業員、月、業種別協約によって異なるという事実を処理する必要があります。
手動スプレッドシートのユーザーは、各給与明細を個別に読み、該当する数値を適切なセルに入力することで、これらすべての違いに対応します。60行すべてに固定の計算式または固定の列位置を適用するバッチ抽出は、Apecのあるカードル、不安定手当のあるCDD、または他の従業員が受け取らない休暇手当のある非カードルに遭遇した時点で破綻します。抽出メカニズムは、各給与明細をフィールドの意味(「正味支給額」が1ページ目、2ページ目、または付属の表のいずれに表示されていても特定する)に基づいて読み取る必要があり、フィールドの位置に基づいてはいけません。
バッチ処理が解決する3つの問題(単一明細抽出では無視されるもの)
フランスの給与明細1枚からデータを抽出するのは、すでに解決済みの問題です。しかし、それを60枚分行うのはまったく別の問題であり、単に60倍の労力がかかるという違いではありません。
従業員と行のマッチング。 Silaeは給与明細PDFをbulletin_salarie_202605.pdfのようなファイル名でエクスポートします。PayFitはBulletin_de_paie_Mai_2026_Dupont_Marie.pdfを使用します。Sage Paieは従業員番号ベースの方式をデフォルトとします。これらのファイルが60個フォルダに置かれた場合、ファイル名の規則だけでは正しい帰属を保証できません。従業員名や識別子の列を出力しない抽出ツールでは、ユーザーが各行を各PDFに手動で照合する必要があり、バッチ処理で節約した時間が無駄になります。ツールは各給与明細から従業員名(nom du salarié)、従業員番号(matricule)、またはNIR(numéro de sécurité sociale)を抽出し、すべての出力行に専用の列として含める必要があります。
給与プロバイダー間のレイアウトの異質性。 正社員にはSilaeを使用し、契約社員の給与明細はポルタージュ・サラリアル会社から受け取る企業では、同じ月次バッチ内に構造的に異なる2つのPDF形式が混在します。Sage PaieからPayFitに年度途中で移行した企業では、同じ従業員、同じ報告対象期間に対して、Sage形式のPDFが6ヶ月分、PayFit形式のPDFが6ヶ月分存在します。テンプレートベースの抽出ツールは、1つのレイアウトに調整されているため、もう一方では機能しません。フィールドラベルを意味で読み取るセマンティック抽出ツール(「Salaire Brut」「Brut」「Salaire de base imposable」はすべて同じ概念を指す)は、追加設定なしで混在形式のバッチを処理できます。
すべてのPDFを再読せずに検証する。 単一明細抽出後は、2~3枚の給与明細をスポットチェックできます。しかし、60枚をスポットチェックすることはできません。バッチ出力では、異常値を一目で確認できるようにする必要があります。つまり、ゼロまたはマイナスの手取り額、雇用主負担が期待される比率と概ね一致しない行、前月から給与が15%以上変動した従業員などです。これにより、検証作業は60枚すべてのPDFを再読することから、出力をスキャンして異常値を見つけることへと移行します。このワークフローは、抽出出力が列レベルの並べ替えやフィルタリングに十分に一貫した構造化されている場合にのみ機能します。
単一のフランスの給与明細(ブルタン・ドゥ・ペ)のフィールドレベルの複雑さ(16の必須フィールド、5つの社会保険料グループ、課税対象額と手取り額の区別)について詳しくは、フランスの給与明細データをExcelに抽出するガイドをご覧ください。1枚の明細で機能する抽出メカニズムは、60枚でも同じように機能します。しかし、バッチ処理のコンテキストでは、上記の3つの問題が追加されます。これらの問題は、複数のファイルが同じ処理キューに入った場合にのみ発生します。
複数のフランスの給与明細を一つの表にまとめて処理する方法
複数の給与計算プロバイダーから提供される60種類の異なる給与明細PDFを抽出するアプローチは、カスタム列抽出です。これは、必要なフィールド名を入力すると、AIがラベルの意味を理解して各値を特定する仕組みで、ページ上の位置には依存しません。列を一度定義すれば、AIはバッチ内のすべての給与明細を同じ列定義に基づいて読み取ります。従業員1の給与明細がSilae、従業員32がPayFit、従業員47がどちらとも異なるポルタージュ・サラリアルPDFであっても、従業員ごとに1行のスプレッドシートが生成されます。
CSGチェック(総支給額 * 0.9825 * 0.092)と抽出されたCSG合計の比較。別の例:純額検証(課税対象純額 - 源泉徴収額)と抽出された手取り額の比較 — 差額は交通費(indemnité de transport)などの払い戻しに相当します。これらの計算チェックで1ユーロ以上異なる行が、手動レビューが必要な行です。60行すべてをチェックする代わりに、フラグが立った3行だけを確認します。ファイルは安全に処理され、保存されることはありません。
年末・退職時の対応 — バッチ給与データが二度活きる瞬間
毎月のバッチ処理は、年末調整と従業員退職という二つの節目で価値を倍増させる資産を構築します。
年末のDSN統合。毎年1月、会計士や経理チームは12ヶ月分のDSN送信データを総勘定元帳と照合する必要があります。DSNの合計額(総支給額、従業員負担分、事業主負担分、課税対象額)は給与台帳と一致しなければなりません。毎月バッチ処理を行っていれば、各月のExcelエクスポートがワークブックの1シートになります。12枚のシートと1つのピボットテーブルで、12ヶ月分の個別PDFから720行を再入力する必要があった年次照合が、半日の確認作業に短縮されます。フランスの財務書類のバッチ処理について詳しくは、バッチ処理で80件のフランスの仕入先請求書を処理する方法をご覧ください — 給与明細PDFにも仕入先請求書PDFにも同じ単一バッチ統合の原則が適用されます。
最終精算。従業員が退職する場合 — 自己都合退職、解雇、または有期契約の満了 — 雇用主は契約最終日に3つの必須書類を発行しなければなりません:労働証明書、フランス・トラヴァイユ証明書(旧ポール・アンプロワ証明書)、および最終精算の受領書 — 退職時に支払われる全額の明細書です。最終精算では、最終月の給与、未消化の有給休暇、該当する場合は解雇手当、有期契約従業員の場合は不安定雇用手当を計上する必要があります。従業員は精算内容に異議を申し立てるために6ヶ月の猶予があります。毎月の給与明細がすでにデジタル化されているバッチ抽出アーカイブがあれば、雇用主は退職する従業員の完全な報酬履歴を数秒で作成できます。アーカイブされたPDFフォルダを探し回る必要も、12ヶ月分のデータを再構築する必要もありません。最終精算は最後の給与明細です。バッチアーカイブが最初の11ヶ月分が正しかったことを証明します。
フランス・トラヴァイユ証明書の正確性。失業手当のための雇用主証明書では、雇用主は従業員の過去12ヶ月間の総支給額と契約終了理由を報告する必要があります。この証明書の給与額は、フランス・トラヴァイユが計算する従業員の失業手当額を直接決定します。誤り — たった1ヶ月の総支給額の間違い — が、雇用主が修正証明書を発行する間、従業員の手当を数週間遅らせる可能性があります。バッチ抽出では、すべての行が元の給与明細から取得され、手動で転記されない12ヶ月分の給与履歴が生成されるため、証明書修正の原因となる転記ミスを最小限に抑えられます。
複数年にわたる給与記録アーカイブ。フランスの雇用主は、労働法典第L3243-4条に基づき、給与記録を5年間保管する義務があります。従業員60人の1年で720枚のPDFが発生し、3年で2,160枚、5年で3,600枚になります。各バッチを進みながら構造化されたExcelアーカイブに変換することで、5年後には3,600枚のPDFフォルダではなく、検索可能なデジタル給与台帳が手に入ります。URSSAFの調査やDSNコンプライアンスレビューに必要な監査証跡は、列ごと、月ごと、従業員ごとにすでに構造化されています。
チームで個別レコードから統合給与台帳を構築する場合、バッチ抽出により台帳構造に必要な行レベルのデータが得られます。給与明細データをExcelに個別抽出する場合も、同じカスタム列抽出メカニズムが適用されます。違いは規模だけです。同じ抽出原理を韓国の給与明細に適用した例(韓国人従業員の給与明細のバッチ処理参照)では、規制の枠組みは変わりますが、バッチワークフローは同一です。列を定義し、バッチをアップロードし、1つのテーブルをエクスポートします。
よくある質問
Silae、PayFit、Sage Paieの給与明細を同じバッチで処理できますか?
はい。カスタム列抽出は、フィールドラベルを位置ではなく意味で読み取ります。Silaeの「Salaire Brut」、PayFitの「Brut」、Sage Paieの「Salaire de base imposable」は、すべて総支給額として認識されます。列を一度定義すれば、AIが同一バッチキュー内の給与プロバイダー間のレイアウトの違いを処理します。
非管理職(非Cadre)の従業員にApec拠出がない場合など、データが欠落している行はどうなりますか?
その行のセルは空欄になります。管理職(Cadre)の従業員にはApec列に値が入り、非管理職の従業員は空欄になります。列構造は60行すべてで一貫しており、空欄は意図的で追跡可能であり、データエラーではありません。有期契約(CDD)従業員の不安定手当(indemnité de précarité)が最終明細にのみ表示される場合、その列は1~Nヶ月目は空欄で、契約終了月のみ値が入ります。
フランスの給与明細にある密集した数値表の抽出精度はどのくらいですか?
フランスの給与明細(bulletin de paie)の印刷テキストと数値表は、最大99%の精度で抽出されます。拠出金ブロックが密集しているほど(Silae生成のPDFによっては15行の控除が1つの表に詰め込まれる場合あり)、DSNクロスチェック計算列の重要性が増します。抽出されたCSG合計が計算上のCSG(総支給額×98.25%×9.2%)と1ユーロ以上異なる行は、手動レビュー用にフラグが立てられます。これにより、確認作業が全60行のチェックから、フラグが立てられた行(通常バッチあたり5行未満)のチェックに変わります。
バッチ抽出は、スキャンまたは撮影された紙の給与明細も処理できますか?
はい。AIは、PDFに埋め込まれたテキストレイヤーではなく、ページの視覚的な内容(テキスト、表、数字)を読み取ります。印刷された給与明細のスキャンやスマートフォン写真も、ネイティブのデジタルPDFと同一バッチで処理できます。これは特に、過去のアーカイブで重要です。企業がSilaeやPayFitを導入する前の紙の給与明細をスキャンし、現在のデジタルPDFと同じスプレッドシート構造にバッチ抽出できます。
これは給与ソフトウェアの代替になりますか?
いいえ。Silae、PayFit、Sage Paieは、給与計算、税率適用、DSN送信管理、毎年1月に変わる規制更新を処理します。バッチ抽出は、それらのシステムからのPDF出力を取得し、内部報告、DSNクロスチェック、アーカイブ用に1つのスプレッドシートに統合します。これは、給与ソフトウェア自体が個々の従業員ファイル間で実行しない統合ステップです。
複数ページの給与明細について — シニア社員のSilae明細は3ページになることもありますが?
複数ページの給与明細は1つの書類として処理されます。AIがPDFの全ページを順次読み取った後にフィールドを抽出します。2ページ目の差引支給額は、1ページ目の従業員名や3ページ目の社会保険料明細と同じ行に抽出されます。同じ明細内で別のページに記載されたフィールドが失われることはありません。
60枚の給与明細、12ヶ月、720行 — 抽出と手入力の時間差は年間数十時間に及びます。しかし重要なのは業務の変化です。月次給与の統合が数時間から数分になれば、経理チームはDSNを送信前ではなく送信後に確認できるようになります。過去の全給与明細が構造化アーカイブに格納されれば、退職精算やURSSAF調査の際に、数日がかりの書類探しではなく、クエリを実行するだけで済みます。バッチ処理は給与明細のデータを変えるのではなく、そのデータを活用できるタイミングを変えるのです。