40枚の給与明細PDF、
1つのスプレッドシートに
毎月末日がSistema RED送信の締切です。A3、Sage、NominaSol、PayFitなどの給与計算ソフトは、各従業員の給与明細を正しく計算しています。基本給、手当、5種類に分類された社会保障料、個別の源泉徴収率に基づく所得税、そして各ページ下部の事業主負担額まで。しかし、それら40枚のPDFを1つの表に統合することはできません。また、2015年から直接清算制度で旧TC2に代わったRNT（従業員別社会保障料明細）や、四半期ごとの所得税源泉徴収申告書であるModelo 111には、従業員ごとのデータが必要です。40枚のPDFがフォルダにあり、スプレッドシートは空のまま。締切が迫っています。
重要ポイント
- 40枚の給与明細PDFがフォルダにあり、Sistema REDの締切は明日。給与計算ソフトはすべて正しく計算したが、1つの表に統合していない。
- 抽出処理に組み込まれた3つの計算列により、検証作業が40行から、数式が不一致を示す3～5行に削減される。
- ImageToTable.aiで19の給与計算列を一度定義し、40ファイルを一括処理すれば、RNTのクロスチェックがSistema RED確認後ではなく前に行える。これは、フォルダ内の給与計算プロバイダ数に関係なく、毎月再現可能。
なぜスペインの給与計算ソフトは40ファイルも作成し、統合スプレッドシートを作らないのか
スペインの給与計算ソフトは、スプレッドシートを作成するために設計されていません。給与を正しく計算し、その結果をSistema RED（スペインのすべての雇用主が毎月の社会保障拠出報告を行う電子申告システム）を通じてTesorería General de la Seguridad Social（TGSS）に送信するために設計されています。Sistema de Liquidación Directa（SLD）では、雇用主はfichero de bases（拠出ベースファイル）を介して労働者ごとの拠出ベースを送信します。TGSSは、会社が支払うべき総額を示すRLC（Recibo de Liquidación de Cotizaciones、旧TC1）と、労働者ごとの拠出ベース、日数、契約タイプの詳細を示すRNT（Relación Nominal de Trabajadores、旧TC2）で応答します。
このアーキテクチャは、スペインのすべての人事部門やgestoría（給与計算代行会社）が直面するギャップを生み出します。給与計算ソフトは、Estatuto de los Trabajadores第29条に基づき各従業員が受け取る法的な領収書として、個別の給与明細（nómina）PDFを生成します。その後、ソフトは集計された拠出データをSistema REDに送信します。しかし、個別のPDFと集計送信の間にはブラックホールが存在します。A3、Sage NominaPlus、NominaSolのいずれにも、RNTが確定される前にそれら40のPDFを内部検証用の1つの表に統合するボタンはありません。
その結果、毎月の儀式が発生します。各従業員のnómina PDFを開きます。Total Devengado、5つの社会保障控除（共通疾病4.70%、失業1.55%/1.60%、職業訓練0.10%、FOGASA、そして2023年からはMEI 0.15%）、IRPF源泉徴収、ページ下部の雇用主負担額（aportación empresarial）を確認します。各数値をスプレッドシートに入力します。これを40回繰り返します。月を締めます。給与明細1枚あたり2分（異なる給与計算ソフトのレイアウトで位置が変わるフィールドを視覚的に探す時間を含む）と控えめに見積もっても、40人の従業員の会社ではデータ転送だけで月に約80分かかります。12回の給与サイクルで16時間です。そして、これは誰もRNTの合計を個別の給与明細の値と照合しようとする前の話です。
スペインの給与明細の個別フィールドと、それらを抽出する方法の詳細については、スペインの給与明細データをExcelに抽出するガイドをご覧ください。この記事はその続きです。1枚のnóminaから40枚へ、そして単一のPDFから月末報告義務へと移行する際に何が起こるかを説明します。
バッチ処理がつなぐ月次申告パイプライン
40枚の給与明細を1つのスプレッドシートに統合する価値は、表そのものではありません。その表が次に何を生み出すかにあります。スペインの給与コンプライアンスは月次サイクルで動き、2つの異なるデータ要求があり、どちらも同じ源泉（個々のノミナ）からデータを取得します。
Sistema RED / RNT（月次）。事業主はSistema REDプラットフォームを通じて拠出ベースをTGSSに送信する必要があります。提出期間は毎月1日に始まり、最終日の前日までです。支払期限は銀行振込の場合は月末営業日、口座振替（domiciliación）の場合は20日です。RNTを確定する前に、責任ある給与管理者は必ずクロスチェックします。RNT内の全従業員のCCベース合計は、個々のノミナの集計と一致するか？事業主負担（aportación empresarial）の合計は全給与明細の合計と一致するか？RNT草案と基礎となる給与明細データに不一致がある場合、送信・支払いが行われると修正申告（rectificación）が必要となり、労働監督官（Inspección de Trabajo）で発覚した場合はLISOSに基づく制裁対象となります。
Modelo 111（四半期次）。従業員の給与からIRPFを源泉徴収するすべての事業主は、各四半期終了後20日以内にAgencia Tributaria（AEAT）にModelo 111を提出する必要があります。提出期間は4月1日～20日（Q1）、7月1日～20日（Q2）、10月1日～20日（Q3）、1月1日～20日（Q4）です。Modelo 111には、四半期の全従業員のIRPF源泉徴収額（retención）の合計が必要です。スペインの給与明細におけるIRPF税率は一律ではなく、各従業員の推定年間収入、Modelo 145で通知された家族状況、および州の税率区分（19%～47%の累進課税）を補完する自治コミュニティのスケールに基づいて個別に計算されます。各従業員のIRPF源泉徴収額は個々のノミナに記載されています。四半期の合計はModelo 111に記載されます。この間のステップがスプレッドシートです。このスプレッドシートが40枚のノミナを手動で転記して作成された場合、1つの転記ミス（432.15を342.15と入力するなど）でModelo 111の合計が誤りとなり、AEATの照合（最終的に従業員の年次Modelo 100確定申告に現れる）で不一致が指摘されます。
これら2つの申告に加えて、企業は毎月CRA（支払報酬概念）も提出する必要があり、従業員50人以上の企業はReal Decreto 902/2020に基づき、平均給与と手当を性別・職種カテゴリー別に分解したregistro retributivo（給与登録簿）を維持する必要があります。これらの義務はすべて、40枚の個別ノミナPDFに存在する同じデータから取得されます。バッチ統合により、これらの申告はすべて、データ探索の作業から、1つのソースから構築されたピボットテーブルへと変わります。
欧州の国境を越えて給与管理を行っている場合も、同じバッチ統合の原則がフランスの給与明細処理やドイツのLohnabrechnungバッチ抽出に適用されます。規制の枠組みは異なりますが、個別PDFと集計申告の間の運用上のギャップは、欧州のどの給与市場でも同じです。
1つの給与明細が3つのレイアウトに：A3、Sage、NominaSolが固定テンプレートを破る理由
スペインの給与計算ソフトはすべて、同一のOrden ESS/2098/2014モデルに基づく法定準拠の給与明細を生成します。各明細には、encabezado（ヘッダー）、devengos（支給額）、deducciones（控除額）、そして事業主負担を含むbases de cotizaciónパネルの4ブロックが必須です。フィールド自体は固定ですが、ページ上の配置は自由です。
A3 / a3innuwa Nómina（Wolters Kluwer）は、複数クライアントの給与を管理するgestoríasやasesorías laboralesで主流のプラットフォームです。事業主データと従業員データを別々のヘッダーブロックに配置し、支給額を左寄せテーブル、控除額を右寄せテーブル、bases de cotizaciónパネルを下部に全幅で表示するマルチカラムレイアウトを採用しています。Sage NominaPlus（大企業向けSage 200 Laboral含む）は、4ブロックを単一の縦列に配置——ヘッダーが最上部、その下に支給額、さらにその下に控除額、最下部にbasesパネル——し、IRPF源泉徴収率をNIFやCCCとともにヘッダー内に大きく表示します。NominaSol（Software DELSOL）は、無料で永久更新されるモデルで零細企業に人気です。独自のシングルカラムレイアウトで、控除額をコンパクトなテーブルにまとめ、事業主負担を小さなパネルに配置します。
3つの異なるPDFレイアウト。1枚の給与明細あたり同じ16の必須フィールド。テンプレートベースの抽出ツール——A3のPDFで調整済み——は、フィールド位置をピクセル座標やバウンディングボックスとして読み取ります。同じバッチにSage NominaPlusの給与明細が混入すると、A3レイアウトで(x=140, y=320)にあった「Salario Base」フィールドが、Sageレイアウトでは(x=80, y=280)に移動します。テンプレートは古い位置のセルを読み取るため、別の数値——または空白——を取得し、行データが誤ります。さらに、企業が年度途中で給与プロバイダーをSageからPayFitに変更した場合、バッチの半分が一方のレイアウト、残り半分が別のレイアウトになります。同じ列定義に対して2つのテンプレートを作成・維持し、テンプレート#1を行1～6に、テンプレート#2を行7～12に適用したことを手動で確認する作業は、バッチ処理で節約した時間を帳消しにします。
ここでカスタム列抽出が状況を変えます。テンプレートベースのツールとは異なり、セマンティック抽出は各給与明細をフィールドの意味で読み取ります。AIは「Salario Base」という概念ラベルを理解するため、訓練データ内の特定ピクセル位置に依存しません。列名を一度定義すれば、AIはすべての給与明細を同じセマンティック定義に照らして読み取ります。建設会社のA3給与明細、オフィススタッフのSage NominaPlus給与明細、パートタイム従業員のNominaSol給与明細がすべて同じスプレッドシートに集約され、各行が同一の列に揃います。AIが各フィールドの「内容」を読み取り、「位置」を無視するからです。
別のシステムの給与明細を含む同様のクロスプロバイダーバッチシナリオについては、同じアプローチがDouzoneとECOUNTにわたる韓国給与明細の統合をどのように処理するかをご覧ください。給与ソフトの名称は変わりますが、単一バッチ内で異種PDFレイアウトを扱う課題は普遍的です。
スペインの給与明細40件を一括処理し、1つの給与サマリーテーブルにまとめる方法
40名分の給与明細を一括抽出するワークフローは、単一明細の抽出と構造的には同じです。しかし、規模が大きくなると、列の設計、一括処理からファイリングへのパイプライン、そして検証手順がすべて変わります。
ファイルは安全に処理され、保存されることはありません。
従業員名 (Nombre Empleado)
従業員NIF
NAF (社会保障番号)
支払期間 (Periodo)
基本給 (Salario Base)
手当 (Complementos)
按分賞与 (Prorrata Pagas)
総支給額 (Total Devengado)
社会保障一般拠出（労働者負担）(Cont. Comunes)
雇用保険（労働者負担）(Desempleo)
職業訓練（労働者負担）(Formacion Prof.)
MEI（労働者負担）
IRPF源泉徴収 (Retencion IRPF)
控除合計 (Total a Deducir)
手取り額 (Liquido a Percibir)
CC算定基礎額 (Base CC)
社会保障一般拠出（事業主負担）(Aport. Empr. CC)
雇用保険（事業主負担）(Aport. Empr. Desempleo)
事業主負担合計 (Aport. Empr. Total)
- 照合チェック：
Total Devengado − Total a Deducir − Líquido a Percibir— ゼロであるべき。ゼロ以外の行は即座にフラグが立ちます。 - 社会保険料率チェック：
CC Base × 4.70% − Cont. Comunes Worker— ±1 €以内であるべき。誤ったベースが読み取られた行にフラグが立ちます。 - IRPF整合性： IRPF率のパーセンテージとIRPF額を抽出する場合、
Base Sujeta IRPF × Rate% − Retencion IRPFで源泉徴収の異常にフラグが立ちます。
リモート社員、サテライトオフィス、外部給与計算代行業者など、複数の拠点から給与明細ファイルを受け取る必要があるチームには、コレクションリンクを使用すると、各社員やオフィスが直接nómina PDFをアップロードできます。ファイルは自動的に処理キューに追加されるため、一括処理前にメールでPDFを追跡する手間が省けます。
スケール検証：40行が3行のフラグ対象に絞られる理由
1枚の給与明細を手動で検証する方法（各フィールドを目視確認し、数値の妥当性を確認する）は、40枚には対応できません。バッチ抽出後に2～3枚をスポットチェックすることは可能ですが、40枚すべてをチェックしてSistema REDの期限（前日）に間に合わせることはできません。検証方法は、手動によるフィールド単位の確認から外れ値検出へと移行する必要があります。つまり、抽出結果から計算上の関係が崩れている行をスキャンし、該当行のみを確認する方法です。
抽出処理（上記ステップ3）に組み込まれた3つの計算列により、この移行が可能になります。
| チェック項目 | 計算式 | 調査が必要なケース | 最も多い原因 |
|---|---|---|---|
| 給与収支 | 総支給額 − 控除額合計 − 手取り額 | 結果 ≠ 0 ±0.50 € | 控除が支給として誤分類、または臨時給与（pagas extras）が誤った小計に含まれている |
| 社会保障（CC）率 | CC基準額 × 4.70% − 抽出された労働者負担の共通拠出金 | 乖離 > ±1 € | 誤った基準額を読み取り（CC基準ではなくAT/EP基準を取得）、または従業員が上限基準額（2026年：5,101.20 €/月）に達している |
| 失業保険率の推測 | 失業保険額 / ATEP基準額を計算。約1.55% → 無期契約（Indefinido）、約1.60% → 有期契約（Temporal） | いずれの率にも一致しない | 固定期間不定期契約（Fijo-discontinuo、率1.55%を使用）、または失業保険が一部のみ計上された修正給与明細 |
| MEIの有無 | 給与明細にMEI行が存在するか確認（2023年導入、2026年の労働者負担率0.15%） | 一部の行にMEIがあり、他の行にない | 実習契約（contrato formativo）などMEI免除対象の従業員 — エラーではなく、分類が必要 |
失業保険率チェックには別の目的もあります。給与ソフトウェアのエクスポートに別途列を設けなくても、契約タイプを特定できることです。推測列（AIが文書内容に基づいて各行をカテゴリに分類）により、給与明細に印刷された失業保険率から「無期契約」または「有期契約」を出力できます。これは、従業員マスター台帳を管理し、契約分類の一貫性が求められる企業で、給与ソフトウェアのPDF明細にこの項目が含まれていない場合に有用です。
個々の給与明細レコードを構造化された給与台帳に変換するためのより広範な設定については、バッチ処理を支えるのと同じカスタム列抽出メカニズムが台帳構造にも適用されます。違いは頻度です。バッチ統合は毎月行われ、台帳は12か月分のバッチ出力を累積したものです。
よくある質問
A3、Sage、NominaSolの給与明細を同じバッチで一括処理できますか？
はい。カスタム列抽出は、位置ではなく意味でフィールドラベルを読み取ります。A3の給与明細の「Salario Base」、Sage NominaPlusの給与明細の同じラベル、NominaSolの給与明細の「S. Base」はすべて同じ抽出列にマッピングされます。列名は一度定義するだけです。フォルダ内にいくつの異なる給与プロバイダやPDFレイアウトがあっても、バッチは40ファイルすべてを同じ定義に対して処理します。
年俸の按分支給（pagas extras）がある従業員とない従業員が同じバッチに混在する場合、どのように処理されますか？
賞与が按分（prorrateadas）されている場合（6月と12月に支給される代わりに12ヶ月の給与明細に分散）、「Prorrata Pagas Extras」という行が表示されます。按分されていない場合、6月と12月の給与明細には別のブロックが表示され、Total Devengadoがはるかに大きくなります。「Prorrata Pagas Extras」列を抽出すると、按分されている従業員は毎月その列に値が入り、按分されていない従業員は6月と12月以外は空白になります。また、賞与行の有無に基づいて各行を「按分あり」または「按分なし」に分類する推論列を定義することもでき、年収分析のピボットテーブルをすぐに作成できるようになります。
CRA（Conceptos Retributivos Abonados）申請についてですが、バッチ抽出で対応できますか？
はい。CRAは月次申請で、従業員ごとの報酬項目（基本給、補助手当、残業代、賞与、その他の収入）を明細化します。これらの項目はすべて給与明細のdevengosブロックにすでに存在します。「Total Devengado」という1つの列ではなく、個別の列（基本給、補助手当、残業代、按分賞与）として抽出すると、CRA申請データは抽出出力ですでに分解されています。各列を全従業員で合計すれば、月ごと、項目ごとのCRA合計額が得られます。
スキャンした紙の給与明細や写真撮影したものはバッチ抽出で処理できますか？
はい。AIはページの視覚的な内容を読み取ります（デジタルPDFに埋め込まれたテキストレイヤーではありません）。そのため、スキャン文書、スマートフォンで撮影した写真、従業員ポータルのスクリーンショットも、ネイティブPDFと同じバッチで処理できます。これは特に、企業が給与をデジタル化する前の過去の給与アーカイブに有効です。何年も前の紙の給与明細をスキャンし、現在のデジタルPDFと同じ構造化されたスプレッドシートにバッチ抽出できます。スペインの雇用主は給与記録を5年間保管する義務があり、バッチ抽出によりそれらの保管箱が検索可能なデータに変わります。
訂正給与明細（nóminas de rectificación）はバッチでどのように処理されますか？
訂正給与明細が通常の月次給与明細と同じバッチに含まれる場合、それを区別するための分類列が必要です。AIが内容を読み取って文書タイプを判別する推論列を使用すると、各行に「通常」または「訂正」を出力できます。訂正給与明細には、元の金額、訂正差分、新しい合計額が表示されることがよくあります。分類列がないと、訂正行の値が元の月の数値を上書きし、ピボットテーブルで気付かないうちに置き換わってしまいます。分類列があれば、元の値と訂正値の両方が表示され、監査証跡が保持されます。
バッチ抽出は給与ソフトを置き換えるものですか？
いいえ。給与ソフト（A3、Sage、NominaSol、PayFitなど）は、給与計算、保険料率の適用、従業員ごとの個別税率に基づくIRPF源泉徴収処理、頻繁に変わる法改正への対応、Sistema REDやAEATへのデータ送信を行います。バッチ抽出は、それらのシステムが生成するPDF出力を取得し、内部検証、照合、アーカイブのために統合するものです。これは給与ソフト自体が行わない統合ステップです。抽出結果は計算を行う必要はありません。給与ソフトがすでに計算した数値を、RNT検証、Modelo 111、月次給与仕訳がすべて単一のソースとして使用できる構造化形式に忠実に転送する必要があります。
40枚の給与明細PDF、1つのフォルダ、1つの締切。ボトルネックは給与計算そのものではなく、PDFと申告の間のステップ、つまり給与計算実行後、RNT確認とModelo 111提出前に存在すべきスプレッドシートです。一括抽出がそのギャップを埋めます。40枚の給与明細が数分で1つの表に統合されれば、RNTのクロスチェックはSistema RED送信後ではなく前に行えます。すべての社会保障料が独自の列にあり、所得税が明確に分離されていれば、不一致の原因を特定するのに40枚のPDFを開き直す必要はなく、数秒で該当する控除項目にたどり着けます。給与明細データ自体は変わりません。変わるのは、それを活用できるタイミングです。