スペインの給与明細40件、
1つの集計表に
月の最終前日がSistema RED送信の締め切りです。A3、Sage、NominaSol、PayFitなどの給与ソフトは、各nómina（給与明細）をすでに正しく計算しています。基本給、補助手当、5つの区分に分けられたSeguridad Social控除、従業員ごとの税率で計算されたIRPF源泉徴収、各ページ下部の事業主負担分（aportación empresarial）まで。しかし、それらの40通の個別PDFを1つの表に統合することはしていません。また、RNT（Relación Nominal de Trabajadores、2015年以降、旧TC2に代わってSistema de Liquidación Directaで使用されている従業員ごとの社会保険料明細）には従業員単位のデータが必要です。四半期ごとのIRPF源泉徴収申告書であるModelo 111にも同様の要件があります。40通のPDFがフォルダにあります。集計表は空のまま。締め切りが迫っています。
重要なポイント
- 40通の給与明細PDFがフォルダにあり、Sistema REDの締め切りは明日に迫っています。給与ソフトはすべての数字を正しく計算しましたが、それらを1つの表に統合することはしていません。
- 抽出処理に組み込まれた3つの計算列により、検証の負担が40行から、数式が不一致を示す3〜5行にまで軽減されます。
- 19の給与列をImageToTable.aiで一度定義し、40ファイルすべてを一括処理すれば、RNTの照合はSistema RED確認の後ではなく前に行われます。フォルダ内に給与プロバイダーがいくつあっても、毎月再現可能です。
スペインの給与計算ソフトが40ファイルを生成しても集計表を作らない理由
スペインの給与計算ソフトは、集計表を出力するようには設計されていません。給与を正確に計算し、その結果をSistema REDを通じてTesorería General de la Seguridad Social（TGSS、社会保障庁）に送信するために設計されています。Sistema REDとは、スペインのすべての雇用主が毎月の社会保障料申告を行うための電子申告システムです。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つの社会保障控除（contingencias comunes 4.70%、desempleo 1.55%/1.60%、formación profesional 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つの異なるデータ要件があり、どちらも同じ源泉、つまり個々の nómina（給与明細）からデータを取得します。
Sistema RED / RNT（月次）。 雇用主はSistema REDプラットフォームを通じてTGSSに保険料算定基礎額を送信する義務があります。提出期間は月の初日から月末の前日までです。支払期限は、銀行振込の場合月末の最終営業日、口座振替（domiciliación）の場合は20日です。RNTを確定する前に、責任ある給与担当者は必ず照合します：RNT内の全従業員のCC算定基礎額の合計は、個々の nómina の合計と一致しているか？雇用主負担分（aportación empresarial）の合計は、全給与明細の合計と一致しているか？RNTドラフトと基となる給与明細データの間に差異がある場合、送信・支払いが行われると訂正申告（rectificación）となり、労働監督調査（Inspección de Trabajo）で発見された場合は、LISOSに基づく制裁の対象となります。
Modelo 111（四半期）。 従業員の給与からIRPF（所得税源泉徴収）を控除するすべての雇用主は、各四半期の最初の20日以内に税務署（Agencia Tributaria、AEAT）へModelo 111を提出する義務があります：4月1日〜20日（第1四半期）、7月1日〜20日（第2四半期）、10月1日〜20日（第3四半期）、1月1日〜20日（第4四半期）。Modelo 111では、当該四半期の全従業員にわたるIRPF源泉徴収額（retención）の合計が必要です。スペインの給与明細におけるIRPF税率は一律のパーセンテージではなく、各従業員の推定年間所得、Modelo 145で申告された家族状況、州税区分を補完する自治共同体の税率表（19%〜47%の累進課税）に基づいて個別に計算されます。各従業員のIRPF源泉徴収額は個々の nómina に記載されています。四半期の合計はModelo 111に記載されます。その間をつなぐのが集計表です。この集計表が40枚の nómina を手作業で転記して作成された場合、1つの転記ミス（432.15と入力すべきところを342.15と入力）だけでModelo 111の合計が誤りとなり、AEATの照合（最終的に従業員の年間Modelo 100税務申告に反映される）で不一致が検出されます。
これら2つの申告に加えて、企業は毎月CRA（Conceptos Retributivos Abonados、支払済み報酬項目）も提出する必要があります。これは支払われた報酬項目の詳細な内訳です。また、従業員50人以上の企業は、Real Decreto 902/2020に基づき、性別・職種別に平均給与と諸手当を分解したregistro retributivo（給与登録簿）を維持する義務があります。これらの義務はすべて、40枚の個別の nómina PDFに存在する同じデータから取得されます。バッチ処理による一括処理は、これらの各申告をデータ探索の作業から、1つのソースから構築されたピボットテーブルへと変えます。
ヨーロッパの国境を越えて給与計算を管理している場合も、同じ一括統合の原則が、フランスの給与明細（bulletin de paie）処理やドイツの給与明細（Lohnabrechnung）一括抽出にも当てはまります。規制の枠組みは異なりますが、個別のPDFと集計申請の間にある運用上のギャップは、ヨーロッパのどの給与計算市場でも同じです。
1つのnóminaが3つのレイアウトになるとき：A3、Sage、NominaSolが固定テンプレートを壊す理由
スペインの給与計算ソフトウェアはすべて、同じOrden ESS/2098/2014モデルに基づいて、法的に準拠したnómina（給与明細）を生成します。各nóminaには、encabezado（ヘッダー）、devengos（支給額）、deducciones（控除額）、および雇用主のaportación empresarial（事業主負担分）を含むbases de cotización（保険料算定基礎）パネルという同じ4つのブロックが含まれていなければなりません。フィールドは必須です。ただし、ページ上の位置は必須ではありません。
A3 / a3innuwa Nómina（Wolters Kluwer）は、複数の顧客企業の給与計算を管理するgestorías（会計事務所）やasesorías laborales（労務事務所）で主流のプラットフォームであり、雇用主と従業員のデータを別々のヘッダーブロックに持つ複数列レイアウト、devengos（支給額）を左寄せテーブル、控除を右寄せテーブル、bases de cotización（保険料算定基礎）パネルを下部に全幅で配置します。Sage NominaPlus（大企業向けのSage 200 Laboralも同様）は、4つのブロックを単一の縦列に配置します。ヘッダーが最上部、その下にdevengos（支給額）、その下に控除、最下部にbasesパネルという順序で、IRPF（所得税源泉徴収）率はNIFやCCCとともにヘッダーに目立つように表示されます。NominaSol（Software DELSOL）は、無料で常に更新されるモデルで零細企業に人気があり、独自の単一列レイアウトを使用し、すべての控除を狭いテーブルにまとめ、aportación empresarial（事業主負担分）を下部の小さなパネルに配置するコンパクトな形式です。
3つの異なるPDFレイアウト。給与明細1枚あたり同じ16の必須フィールド。テンプレートベースの抽出ツール（A3のPDFで調整されたもの）は、フィールド位置をピクセル座標またはバウンディングボックスとして読み取ります。Sage NominaPlusの給与明細が同じバッチに入ると、A3レイアウトでは(x=140, y=320)にあった「Salario Base」フィールドが、Sageレイアウトでは(x=80, y=280)に移動します。テンプレートは古い位置のセルを読み取ります。そこには別の数字、または空白があります。行が正しく出力されません。さらに、企業が年度途中で給与計算プロバイダーを切り替えた場合（たとえばSageからPayFitへ移行した場合）、バッチの半分は1つのレイアウトから、残り半分は別のレイアウトから来ることになります。同じ列定義に対して2つのテンプレートを作成・維持し、テンプレート#1が1〜6行目に、テンプレート#2が7〜12行目に適用されたことを手動で検証することは、そもそも一括処理によって節約できた時間を帳消しにしてしまいます。
ここでカスタム列抽出が状況を変えます。テンプレートベースのツールとは異なり、セマンティック抽出は各給与明細をフィールドの意味で読み取ります。AIは「Salario Base」という概念ラベルを理解するため、そのラベルがトレーニング例の特定のピクセル位置にあるからではなく、その位置を特定します。列名は一度定義するだけです。AIは同じセマンティック定義に基づいてすべての給与明細を読み取ります。建設会社のA3 nómina（給与明細）、オフィススタッフのSage NominaPlus nómina（給与明細）、パートタイム従業員のNominaSol nómina（給与明細）はすべて同じ集計表に取り込まれ、各行が同じ列に揃います。これはAIが各フィールドの「位置」ではなく「内容」を読み取っているためです。
異なるシステムの給与明細を使った同様のクロスプロバイダーバッチ処理シナリオについては、同じアプローチがDouzoneとECOUNTにわたる韓国の給与明細統合をどのように処理するかをご覧ください。給与ソフトウェアの名前は変わりますが、単一バッチ内の異種PDFレイアウトという課題は普遍的です。
スペインの給与明細40枚を1つの給与集計表にバッチ処理する方法
40人分の給与バッチの抽出ワークフローは、単一の給与明細抽出と構造的に同じです。ただし、列の設計、バッチから申告へのパイプライン、検証ステップは、規模が大きくなるとすべて変わります。
ファイルは安全に処理され、保存されません。
Employee Name (Nombre Empleado)
Employee NIF
NAF (SS Number)
Pay Period (Periodo)
Base Salary (Salario Base)
Complements (Complementos)
Prorated Extra Pay (Prorrata Pagas)
Total Accrued (Total Devengado)
SS CC Worker (Cont. Comunes)
SS Unemployment Worker (Desempleo)
SS Training Worker (Formacion Prof.)
MEI Worker
IRPF Withholding (Retencion IRPF)
Total Deductions (Total a Deducir)
Net Pay (Liquido a Percibir)
CC Base (Base CC)
Employer CC (Aport. Empr. CC)
Employer Unemp. (Aport. Empr. Desempleo)
Employer Total (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件のフラグ付き行になる理由
単一の給与明細を手動で検証する方法（各フィールドを目視確認し、数値が正しいことを確認する）は、40件には対応できません。バッチ抽出後に2～3件の給与明細をスポットチェックすることは可能です。しかし、40件すべてをスポットチェックしながら、Sistema REDの前日締切に間に合わせることはできません。検証方法は、手動によるフィールド単位の確認から外れ値検出へと移行する必要があります。つまり、抽出結果から計算上の関係が崩れている行をスキャンし、該当行のみを確認します。
抽出処理（上記ステップ3）に組み込まれた3つの計算列により、この移行が可能になります。
| チェック項目 | 計算式 | 調査が必要な場合 | 最も一般的な原因 |
|---|---|---|---|
| 給与収支 | 総支給額 − 控除額合計 − 手取額 | 結果 ≠ 0 ±0.50 € | 控除が収入として誤分類されている、または臨時ボーナス行が誤った小計に含まれている |
| 社会保障率 | 共通拠出基準額 × 4.70% − 抽出された労働者負担共通拠出額 | 乖離 > ±1 € | 誤った基準額を読み取り — ツールが共通拠出基準額ではなくAT/EP基準額を取得、または従業員が上限基準額（2026年：5,101.20 €/月）に達している |
| 失業保険率推測 | 失業保険額 / ATEP基準額を抽出。約1.55% → 無期契約、約1.60% → 有期契約 | 率がいずれにも一致しない | 固定期間不定期契約（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通のnómina（給与明細）PDFが1つのフォルダにあり、締め切りは1つ。ボトルネックは給与計算ではありません。ソフトウェアはすでに正しく処理しています。ボトルネックはPDFと申告の間のステップ、つまり給与計算後、RNTが確定しModelo 111が提出される前に存在すべき集計表です。一括処理がそのギャップを埋めます。40通の給与明細が数分で1つのテーブルに統合されれば、Sistema RED送信の前にRNTの照合が行われます。すべての社会保険料（Seguridad Social）が独自の列にあり、IRPFが明確に分離されていれば、差異の追跡は40通のPDFを開き直す代わりに、1つの控除行を確認するだけです。nóminaのデータは変わりません。処理方法が変わるだけです。