40枚の給与明細PDF、
1つのスプレッドシートに
毎月末日がSistema RED送信の締切です。A3、Sage、NominaSol、PayFitなどの給与計算ソフトは、各従業員の給与明細を正しく計算しています：基本給、補助手当、5種類に分類された社会保障控除、個別の源泉徴収率に基づくIRPF、各ページ下部の事業主負担額。しかし、それら40枚の個別PDFを1つの表に統合することはできません。また、2015年以降のSistema de Liquidación Directaで旧TC2に代わるRNT（Relación Nominal de Trabajadores、従業員ごとの社会保障拠出明細）や、四半期ごとの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 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に基づく制裁対象となります。
モデル111（四半期次）。従業員の給与からIRPFを源泉徴収するすべての事業主は、各四半期終了後20日以内にモデル111を税務庁（AEAT）に提出する必要があります。提出期間は4月1日～20日（第1四半期）、7月1日～20日（第2四半期）、10月1日～20日（第3四半期）、1月1日～20日（第4四半期）です。モデル111には、四半期の全従業員のIRPF源泉徴収額（retención）の合計が必要です。スペインの給与明細におけるIRPF税率は一律ではなく、各従業員の推定年間収入、モデル145で通知された家族状況、および州の税率区分（19%～47%の累進課税）を補完する自治コミュニティの税率表に基づいて個別に計算されます。各従業員のIRPF源泉徴収額は個々のノミナに記載されています。四半期の合計はモデル111に記載されます。この間のステップがスプレッドシートです。このスプレッドシートが40枚のノミナを手動で転記して作成された場合、1つの転記ミス（432.15を342.15と入力するなど）があるだけで、モデル111の合計が誤りとなり、AEATの照合（最終的に従業員の年次モデル100確定申告に反映される）で不一致が検出されます。
これら2つの申告に加えて、企業は毎月CRA（支払報酬概念）も提出する必要があります。また、従業員50人以上の企業は、Real Decreto 902/2020に基づき、平均給与と手当を性別および職業カテゴリー別に分解したregistro retributivo（給与登録簿）を維持する必要があります。これらの義務はすべて、40枚の個別ノミナPDFに存在する同じデータから取得されます。バッチ統合により、これらの各申告は、データ探索の作業から、1つのソースから構築されたピボットテーブルへと変わります。
欧州の国境を越えて給与管理を行っている場合も、同じバッチ統合の原則がフランスの給与明細処理およびドイツの給与明細バッチ抽出に適用されます。規制の枠組みは異なりますが、個別PDFと集計申告の間の運用上のギャップは、欧州のすべての給与市場で同じです。
1つの給与明細が3つのレイアウトに：A3、Sage、NominaSolが固定テンプレートを破る理由
スペインの給与計算ソフトはすべて、同一のOrden ESS/2098/2014モデルに基づく法定準拠の給与明細を生成します。各明細には、encabezado（ヘッダー）、devengos（支給額）、deducciones（控除額）、そして事業主負担のaportación empresarialを含むbases de cotizaciónパネルの4ブロックが必須です。フィールドは必須ですが、ページ上の位置は任意です。
A3 / a3innuwa Nómina（Wolters Kluwer）は、複数の顧客企業の給与計算を管理する会計事務所や労務コンサルタントで主流のプラットフォームです。雇用主と従業員のデータを別々のヘッダーブロックに配置し、支給額を左寄せテーブル、控除額を右寄せテーブル、bases de cotizaciónパネルを下部に全幅で表示するマルチカラムレイアウトを採用しています。Sage NominaPlus（大企業向けSage 200 Laboralも含む）は、4ブロックを単一の縦列に配置——ヘッダーが最上部、その下に支給額、さらにその下に控除額、最下部に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への移行）、バッチの半分が一方のレイアウト、残り半分が別のレイアウトになります。同じ列定義に対して2つのテンプレートを構築・維持し、テンプレート#1が1～6行目に、テンプレート#2が7～12行目に適用されたことを手動で確認する作業は、バッチ処理で節約した時間を帳消しにします。
ここでカスタム列抽出が状況を変えます。テンプレートベースのツールとは異なり、セマンティック抽出は各給与明細をフィールドの意味で読み取ります。AIは「Salario Base」という概念ラベルを理解するため、そのラベルが学習例の特定ピクセル位置にあったかどうかではなく、そのラベルを探します。列名を一度定義すれば、AIはすべての給与明細を同じセマンティック定義に照らして読み取ります。建設会社のA3給与明細、オフィススタッフのSage NominaPlus給与明細、パートタイム従業員のNominaSol給与明細がすべて同じスプレッドシートに収まり、各行が同じ列に揃います。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枚の給与明細PDF、1つのフォルダ、1つの締切。ボトルネックは給与計算そのものではなく — ソフトウェアはすでに正しく計算している — PDFと申告の間のステップ、つまり給与計算実行後、RNT確認とModelo 111提出前に存在すべきスプレッドシートです。一括抽出がそのギャップを埋めます。40枚の給与明細が数分で1つの表に統合されれば、RNTのクロスチェックはSistema RED送信後ではなく前に行えます。すべての社会保障拠出が独自の列にあり、IRPFが明確に分離されていれば、不一致の原因を特定するのに40枚のPDFを再確認する必要はなく、1つの控除行を確認するだけです。給与明細データ自体は変わりません。それをいつ活用できるようになるかが変わるのです。