ドイツの賃金税証明書（Lohnsteuerbescheinigung）：
Excelへのデータ抽出方法
ドイツ人従業員80人の会社は、毎年2月に80通のPDF形式の賃金税証明書を受け取ります。これを生成した給与システム（DATEV LODAS、Lexware Lohn+Gehalt、または税理士（Steuerberater）の独自エクスポート）は、すべての項目にドイツ語のラベルを付けています：総課税賃金（Bruttoarbeitslohn）、源泉徴収所得税（einbehaltene Lohnsteuer）、連帯付加税（Solidaritätszuschlag）。ロンドンやニューヨークのグローバル報酬チームは、これらの数値を英語で、1つのExcelファイルに、80行と「Gross Salary」「Income Tax Withheld」「Pension Contributions」などの列で必要としています。標準的な方法（各PDFから各項目をコピーする）では、2月が手動データ入力の突貫作業になります。別の方法があります。それは、ドイツの給与用語を学んだり、証明書のレイアウトごとにテンプレートを作成したりする必要はありません。
重要ポイント
- 毎年2月に税理士（Steuerberater）から80通のドイツ語の賃金証明書PDFが届きます。そして、Excelファイルはありません。なぜなら、ドイツの税法は、証明書自体を法的な給与出力として指定しており、構造化データとしては指定していないからです。
- DATEVやLexwareからの給与ソフトウェアCSVエクスポートは、税務署（Finanzamt）が権威とみなす確定した年間調整ではなく、内部データベーススキーマを保持しています。つまり、エクスポートされたすべての数値を、同じPDFと照合して検証する必要があるのです。
- 英語で「Gross Salary」と入力すると、ImageToTable.aiがドイツ語の賃金税PDF上の総課税賃金（Bruttoarbeitslohn）を特定します。80通の証明書にわたる500回の手動項目検索が、税務署（Finanzamt）がすでに検証した唯一の給与記録から抽出された、1つのバッチスプレッドシートに集約されます。
なぜLohnsteuerbescheinigungは12月分の給与明細を合算しただけでは不十分なのか
ドイツの月次給与明細書（GehaltsabrechnungまたはLohnabrechnung）には、1か月分の収入と控除が表示されます。12か月分の給与明細を合算すれば年間の全体像が把握できると思うかもしれませんが、実際はそうではありません。Lohnsteuerbescheinigung（§41b EStGに基づき義務付けられた公式な年間賃金税証明書）は、月次給与明細の単なる合計ではありません。これは独自のデータ照合プロセスを持つ独立した法的文書であり、翌課税年度の2月28日までにELSTERポータルを通じて税務署（Finanzamt）に電子的に送信されます。月次給与明細には後日修正される可能性のある誤りが含まれることがありますが、Lohnsteuerbescheinigungは、稼得額と源泉徴収額に関する最終的かつ法的拘束力のある明細です。
国際チームにとって、Lohnsteuerbescheinigungと通常の給与明細書を分ける構造上の違いは、データ抽出の観点で重要となる以下の3点です。
税務署（Finanzamt）にとっての公式情報源であり、あなたのものではない。2013年以降、ドイツの雇用主は賃金税データをELStAMシステム（Elektronische Lohnsteuerabzugsmerkmale、電子的賃金税控除特性）を通じて電子的に送信することが義務付けられています。雇用主が§93c AOに基づきELSTER証明書で認証して税務署に送信するデータは、証明書に記載される内容と同じものです。証明書の数字と月次給与明細の数字が一致しない場合、証明書が優先されます。そのため、月次データを集計するよりも、証明書から直接抽出する方が信頼性が高いのです。
給与明細書では別々に報告される控除を統合する。月次給与明細書には、所得税（Lohnsteuer）、連帯付加税（Solidaritätszuschlag）、教会税（Kirchensteuer）が個別の項目として表示されますが、賞与、一時金、税級の変更などにより月ごとに変動する場合があります。Lohnsteuerbescheinigungはこれらを最終的な年間値に確定します。グローバルなFP&Aシステムに必要なのは、確定された数値であり、照合すべき12か月分の生の控除データではありません。
月次給与明細書には決して表示されない項目を報告する。非課税の雇用主給付 — 外勤時食事手当（Verpflegungsmehraufwand）、二重家計（doppelte Haushaltsführung）、転居費用 — は、月次に対応する項目がない年間証明書の各欄に集計されます。総報酬の報告にこれらを含める必要がある場合、月次給与明細書だけでは対応できません。
クロスボーダーの給与照合において、Lohnsteuerbescheinigungからの抽出は近道ではなく、正しいデータソースです。この証明書は、税務署（Finanzamt）が各従業員の最終的な税額を計算するために使用するものです。それ以外のものを使用すると、税務署が受け入れない照合リスクが生じます。
27の番号付きフィールド：あなたのレポート作成に本当に必要なもの
賃金税証明書（Lohnsteuerbescheinigung）は、税務申告の行に対応する番号付き項目（Positionen）を持つ標準化されたレイアウトに従います。DATEV LODAS、Lexware Lohn+Gehalt、Sage Personalwirtschaft、SAP HCM、Personioの給与計算準備モジュールなど、すべてのドイツの給与システムが同じフィールド番号を出力します。レイアウトは異なります。DATEVの証明書は密度が高く、等幅フォーマットのPDFです。PersonioのエクスポートはDATEVに取り込まれ、DATEVのフォーマットを引き継ぎます。税理士（Steuerberater）が少し異なるテンプレートで印刷することもあります。しかし、フィールドの位置は一定です。
ここでは、国際人事・給与レポート作成にとって重要で、その内容ごとにグループ化したフィールドを紹介します。
| No. | ドイツ語のラベル | 英語の相当語 | 必要な理由 |
|---|---|---|---|
| 3 | Bruttoarbeitslohn | 総課税賃金 | 総報酬の報告、クロスボーダー税額調整 |
| 4 | Einbehaltene Lohnsteuer | 源泉徴収所得税 | 外国税額控除の計算、シャドーペイロールの照合 |
| 5 | Einbehaltener Solidaritätszuschlag | 連帯付加税（所得税の5.5%、2021年以降は単身€19,950／夫婦€39,900の控除額を超える場合のみ） | 総税負担の報告。2021年改正後は納税者の約10%に適用 |
| 6 | Einbehaltene Kirchensteuer | 教会税（バイエルン州・バーデン＝ヴュルテンベルク州では所得税の8%、その他の州では9%） | 教会税徴収教会に登録している従業員の手取り額から総支給額への逆算 |
| 22 | Arbeitgeberanteil zur gesetzlichen Rentenversicherung | 法定年金保険雇用主負担分 | 総人件費の計算（雇用主負担分：2025/2026年は9.3%） |
| 23 | Arbeitgeberanteil zur Krankenversicherung | 健康保険雇用主負担分 | 福利厚生費の総額。法定健康保険の雇用主負担分は約7.3%＋追加分 |
| 24 | Arbeitgeberanteil zur Pflegeversicherung | 介護保険雇用主負担分 | 雇用主コストの内訳（雇用主負担分1.8%） |
| 25 | Arbeitgeberanteil zur Arbeitslosenversicherung | 失業保険雇用主負担分 | 雇用主コストの内訳（雇用主負担分1.3%） |
フィールド10〜19は非課税の雇用主給付をカバーしています：食事手当（フィールド21）、二重家計（左欄のフィールド22）、転居費用の払い戻し、財産形成給付（Vermögenswirksame Leistungen）などです。これらは、グローバルモビリティ方針で従業員にネットベースで払い戻しを行い、グロスアップ額を報告する必要がある場合に重要です。ほとんどのクロスボーダー報告では、フィールド3〜6と22〜25が中核となります。
フィールド番号に関する実務上の注意：2025年の証明書レイアウトは、連邦財務省（Bundesfinanzministerium）の2024年9月の指令（BStBl I 2024, 1255）によって確認されています。番号は毎年安定していますが、非課税控除額（Freibeträge）は毎年調整されます。複数の課税年度のデータを取得する場合は、連帯付加税の控除額と社会保険料算定上限額（Beitragsbemessungsgrenzen）の2025年と2026年の変更点を確認してください。
DATEVからExcelへの行き詰まり：給与ソフトの出力では問題が解決しない理由
ドイツの給与計算を税理士（Steuerberater）が処理するDATEV LODASで行っている場合、2月の報告ワークフローはおおよそ次のようになります。税理士（Steuerberater）が給与計算を実行し、電子賃金税証明書（Lohnsteuerbescheinigung）をELSTER経由で税務署（Finanzamt）に送信し、従業員ごとに1つのPDFを含むZIPファイルをメールで送付します。CSVはありません。構造化エクスポートもありません。PDFが成果物なのです。
これは税理士（Steuerberater）が協力的でないという話ではありません。DATEVのアーキテクチャは、税理士（Steuerberater）を仲介者として設計されています。生の賃金データは税理士（Steuerberater）のDATEVインストール内に存在します。雇用主や国際人事チームであるあなたが受け取るのは、法的に準拠した出力形式、つまりPDF証明書です。給与計算処理に対して従業員1人あたり月額15〜35ユーロを請求する税理士（Steuerberater）が、カスタムCSVエクスポートまで構築してくれるわけではありません。税理士報酬規則（StBVV）に基づく彼らの料金体系は、給与計算の「処理」を対象としており、データエンジニアリングは対象外です。
LexwareやSageを実行している社内給与チームは、同じ問題の別の側面に直面しています。これらのプラットフォームはCSVをエクスポートできますが、そのエクスポートは内部の給与データベーススキーマを反映しており、賃金税証明書（Lohnsteuerbescheinigung）の最終調整済み形式ではありません。LexwareのCSVエクスポートは、証明書の連番と1対1で対応しない内部フィールドコードで列にラベルを付けます。結局、エクスポートされた数字を証明書PDFと照合することになります。なぜなら、証明書こそが税務署（Finanzamt）が受け取ったものだからです。
PersonioとDATEVの統合は、この構造的なギャップを最も明確に示しています。Personioの給与準備モジュールは、給与、賞与、欠勤、残業など、給与計算に関連するすべてのデータを収集し、DATEVへのエクスポート用にパッケージ化します（推定従業員1人あたり月額2〜5ユーロ）。しかし、最終的な給与計算を実行するのはPersonioではありません。DATEVです。賃金税証明書（Lohnsteuerbescheinigung）のPDFは、依然として税理士（Steuerberater）を通じてDATEVから提供されます。Personio自身のレポートには、証明書に表示される最終的な税務調整は表示されません。
ボトルネックはソフトウェアではありません。それはドイツの給与計算の構造です。雇用主が委託した給与計算実行は、法的な出力としてPDF証明書を生成します。すべてのエクスポートと統合は、給与データベース構造を維持します。証明書PDFは、すべてのフィールドが確定・調整され、税務署（Finanzamt）が受け取った内容と一致する唯一の文書です。証明書からの抽出は、不具合のあるソフトウェアの回避策ではなく、権威ある文書からの抽出なのです。
列名抽出がテンプレート学習なしでドイツの税証明書を読み取る仕組み
テンプレートベースのOCRツール（ある証明書の「Bruttoarbeitslohn」の周りに四角を描き、そのテンプレートを残りに適用するよう求める種類）は、証明書のレイアウトが変わると失敗します。DATEVのPDF、LexwareのPDF、そしてAddisonソフトウェアを使用する小規模な税理士事務所（Steuerbüro）が印刷した証明書では、同じフィールドが異なる位置に配置されています。テンプレートベースの抽出では、レイアウトのバリエーションごとに個別のテンプレートが必要になるか、レイアウトが変わると誤った値を黙って抽出してしまいます。
カスタム列抽出は異なる仕組みで動作します。フィールドがページ上のどこにあるかを定義する代わりに、出力スプレッドシートに必要な列を名前で定義します。「総賃金」「源泉徴収所得税」「連帯付加税」「年金掛金」など、必要な列ヘッダーを入力します。AIは各証明書PDFを読み取り、フィールドの意味を理解することで対応する値を見つけます。座標を記憶するのではありません。DATEVの証明書とLexwareの証明書は、テンプレートを切り替えることなく同じバッチで処理できます。
このアプローチは、ドイツの賃金税証明書のフィールドラベルがドイツ語であるため、特に重要です。テンプレートベースのツールでは、ページ上の「Bruttoarbeitslohn」というラベルを見つけるよう指示する必要があります。列名抽出ツールでは、「Gross Salaryという列が欲しい」と言うだけで済みます。AIは意味的な意図（「総賃金」）を文書上のドイツ語ラベル（「Bruttoarbeitslohn」）にマッピングします。ラベルテキストが列名と文字通り一致しなくても問題ありません。Position 3が「Bruttoarbeitslohn」と呼ばれていることを知る必要はなく、総賃金の数値が欲しいことを知っていればよいのです。言語マッピングはAIが処理します。
同じ機能で3年間の監査シナリオも処理できます。ドイツ人駐在員の2023〜2025年の報酬を照合するグローバルモビリティチームは、3つの税年度の証明書を必要とします。2023年の証明書はA社（DATEVで処理）から、2024年の証明書はB社（Lexwareで処理）から、2025年の証明書はC社（Personio + DATEVで処理）から来ています。3つの異なるレイアウト、3つの異なるPDF生成元です。列名抽出は、意味的な意味を列名にマッチングさせ、ピクセル位置をテンプレートにマッチングさせないため、同じバッチで3つすべてを読み取ります。
複数従業員のシナリオで計算を変えるさらなる機能があります。推論列を使用すると、単一の印刷フィールドではなく、文書のコンテキストから値を導出する列を定義できます。たとえば、「税負担率」という列を作成し、各従業員について（源泉徴収所得税 + 連帯付加税 + 教会税）÷ 総賃金を計算するようAIに依頼できます。AIは証明書を読み取り、関連フィールドを特定し、計算を実行し、結果を新しい列として出力します。すべて同じ抽出パスで行われます。Excelでの後処理の数式列は不要です。
テンプレートOCRと列名抽出の機能的な違いは、位置をマッピングすることと意味をマッピングすることの違いです。フィールドラベルがレポートチームの読めない言語で書かれている文書の場合、意味のマッピングこそがスケールの前提条件となります。
ステップバイステップ：証明書PDFの束から1つのクリーンなスプレッドシートへ
典型的な2月のシナリオでの抽出ワークフローは次のとおりです。税理士（Steuerberater）が50名のドイツ人従業員分のPDF証明書を送ってきました。ロンドンにあるグローバル報酬チームは、英語の列ヘッダーと従業員ごとの1行を含むExcelファイルを必要としています。
ステップ1：すべての証明書を一度にアップロードします。 50個のPDFをアップロードエリアにドラッグします。このツールはPDF、JPG、PNGに対応しており、一部の証明書がスキャンで、他がネイティブPDFとして届いた場合でも、形式を混在させることができます。まとめてアップロードすることで、単一のバッチとして処理され、1つの結合された出力スプレッドシートが生成されます。
ステップ2：列を英語で定義します。 レポートシステムが期待する列名を入力します。グローバル報酬レポートの場合、典型的な列セットは次のとおりです：
| 列名（英語） | AIが証明書で見つけるもの（ドイツ語） |
|---|---|
| Employee Tax ID | 税務識別番号（Steuer-Identifikationsnummer）（左列、上部セクション） |
| Tax Class | 税級（Steuerklasse）（左列、ELStAMセクション） |
| Gross Salary (EUR) | 総課税賃金（Bruttoarbeitslohn）（位置3） |
| Income Tax Withheld (EUR) | 源泉徴収所得税（einbehaltene Lohnsteuer）（位置4） |
| Solidarity Surcharge (EUR) | 源泉徴収された連帯付加税（einbehaltener Solidaritätszuschlag）（位置5） |
| Church Tax (EUR) | 源泉徴収された教会税（einbehaltene Kirchensteuer）（位置6） |
| Pension Contribution Employee (EUR) | 法定年金保険従業員負担分（Arbeitnehmeranteil zur gesetzlichen Rentenversicherung） |
| Health Insurance Employee (EUR) | 法定健康保険従業員負担分（Arbeitnehmeranteil zur gesetzlichen Krankenversicherung） |
| Unemployment Insurance Employee (EUR) | 失業保険従業員負担分（Arbeitnehmeranteil zur Arbeitslosenversicherung） |
| Long-Term Care Employee (EUR) | 社会介護保険従業員負担分（Arbeitnehmeranteil zur sozialen Pflegeversicherung） |
列定義に計算列を直接追加することもできます。例えば、「Tax Burden Ratio (Income Tax Withheld + Solidarity Surcharge + Church Tax) / Gross Salary」と指定すると、抽出中にAIが計算を実行し、結果を列として出力します — 後からExcelの数式ステップは不要です。あるいは「Total Social Contributions (Sum of Pension + Health + Unemployment + Long-Term Care employee shares)」と指定すれば、社会保険料のワンナンバー数値が得られます。
ステップ3：抽出を実行する。 AIが50枚すべての証明書をバッチ処理します。各ページは5〜10秒かかります。50人分のバッチは数分で完了します。AIは証明書のレイアウトを読み取り、各要求フィールドを意味的に識別し、値を抽出して、指定した列の下に配置します。レイアウトが異なる証明書（DATEVとLexware）も同じパスで処理されます。
ステップ4：確認してエクスポートする。 出力は、50行（従業員ごとに1行）と定義した列を持つテーブルです。スクロールしてスポットチェックできます：従業員37号の総給与は、その役割について知っている内容と一致していますか？ フィールドが欠落している人はいますか？ 確認後、XLSX、CSV、JSONでエクスポートします — 給与システムやFP&Aツールが取り込む形式なら何でも構いません。
このワークフローは、通常数日かかる手作業プロセスを置き換えます：各PDFを開き、各フィールドを見つけ、スプレッドシートにコピーし、ドイツ語のラベルを英語の列に翻訳し、数字を転記ミスしていないことを願う — という作業です。50人の従業員に各10フィールドの場合、抽出を行う人が読めない言語で書かれた文書全体で500回の個別フィールド検索が必要になります。
手動抽出を妨げるバッチシナリオとエッジケース
従業員ごとに複数の証明書。 年度途中で転職した従業員は、各雇用主から別々の賃金税証明書（Lohnsteuerbescheinigung）を受け取ります。証明書は独立した文書であり、それぞれ異なる期間（位置1）をカバーしています。外国税額控除のための従業員の年間総所得を計算するには、証明書間で合算する必要があります。列名抽出では、各証明書を個別の行として扱うことでこれを処理します。Excelで行を合算します。重要なのは、両方の証明書が同じ列構造で抽出され、行が加算可能であることです。
一部の従業員にのみ適用される教会税。 教会税（Kirchensteuer、バイエルン州とバーデン＝ヴュルテンベルク州では8%、その他の連邦州では9%）は、税徴収宗教団体に登録されている従業員にのみ適用されます。教会員でない従業員の場合、証明書のフィールド6は空白またはゼロです。列を定義する際、全従業員に「教会税」を含めてください — AIは非会員には0を返します。これは列を条件付きで含めるよりも安全です。全行で列の一貫性が保たれるからです。
控除額を超えると段階的に適用される連帯付加税。 2021年の改革以降、ドイツの納税者の約90%は連帯付加税を支払っていません。年間所得税が19,950ユーロ（単身）または39,900ユーロ（夫婦合算）を超える従業員のみがSoliを支払い、それも完全な5.5%税率に達する前に緩和ゾーン（Milderungszone）を通じて段階的に適用されます。ほとんどの従業員にとって、フィールド5はゼロになります。それは正しい結果です — 抽出エラーではありません。ドイツ連邦憲法裁判所は2025年3月にSoliの合憲性を支持し、現在の構造が引き続き有効であることを確認しました。
退職した従業員の証明書。 従業員が9月に退職した場合、雇用終了後合理的な期間内に賃金税証明書（Lohnsteuerbescheinigung）を発行することが法的に義務付けられています。退職者を受け入れる新しい雇用主の場合、前職からのPDF証明書を受け取ります — おそらく自社とは異なる給与システムで生成されたものです。両システム間にデータパイプラインはありません。PDFから直接抽出することが、手動再入力なしで前雇用主のデータを報酬記録に取り込む唯一の方法です。
FAQ
ドイツ語の賃金税証明書（Lohnsteuerbescheinigung）PDFで、ドイツ語のフィールドラベルが付いているものも処理できますか？
はい。AIは証明書の内容をドイツ語で読み取り、意味的な一致に基づいて英語の列名にマッピングします。ドイツ語のフィールドラベル翻訳を提供する必要はありません。入力する英語の列名（「Gross Salary」「Income Tax Withheld」など）が、AIがドイツ語の証明書上で対応する値を探すためのラベルになります。
異なるレイアウトの複数の給与システムから証明書が届く場合はどうなりますか？
列名抽出はレイアウトの一貫性に依存しません。DATEVの証明書、Lexwareの証明書、Sageの証明書を同じバッチで処理できます。AIはフィールドがページ上のどこにあるかではなく、その意味に基づいて識別します。異なる形式をまとめてアップロードすれば、同じ列定義で全ファイルに対して抽出が実行されます。
従業員が200人います。200枚すべての証明書をバッチ処理できますか？
はい。バッチ処理がデフォルトのモードです。すべてのファイルをまとめてアップロードすると、AIが順次処理し、結果を1つの出力スプレッドシートにまとめます。完全なバッチ方式の複数従業員ワークフローの詳細については、80名分の証明書が1つのスプレッドシートになる方法をご覧ください。200枚の証明書の処理は50枚より時間がかかりますが、ワークフローは同じです。非常に大きなバッチの場合は、50〜100ファイルの管理しやすいチャンクに分割して中間結果を確認してから、全セットを実行することを検討してください。
スキャンした紙の証明書（デジタルPDFではない）でも抽出できますか？
はい、スキャン品質が十分であれば可能です。印刷された証明書のJPGおよびPNG画像に対応しています。スキャンが大きく傾いている、解像度が低い、または影が大きい場合は、抽出精度が低下します。スマートフォンで撮影した写真も同様です。明るく、平らで、高解像度の写真は機能しますが、斜めやぼやけた撮影では結果が低下します。AIは完璧な300 DPIスキャンを必要としませんが、AIが確実に抽出するには、人間の読者が判読できる程度のテキストの明瞭さが必要です。
従業員の給与データは抽出中に安全ですか？
ファイルは転送中に暗号化され（TLS）、メモリ上で処理されます。アップロードされた文書と抽出結果は、処理完了後すぐにサーバーから自動削除されます。データがAIモデルのトレーニングに使用されることはありません。このアーキテクチャは、永続的な保存ではなく短時間の処理を目的として設計されています。GDPR第28条（データ処理契約）の対象となる組織の場合、標準的な処理条件では、このツールは抽出セッションを超えてデータを保持しない処理者として分類されます。
1つのバッチで複数の課税年度から抽出できますか？
はい。2023年、2024年、2025年の証明書を同じバッチで処理できます。3つの年度すべてが同じフィールド番号（Positionen 1–27）を共有しているため、同じ列定義が全年度に適用されます。実務上の考慮点として、非課税限度額は毎年変動します。連帯付加税の非課税額、社会保険料算定上限額（Beitragsbemessungsgrenzen）、ミニジョブの限度額はすべて調整されます。これらの限度額の変更は証明書に表示される内容に影響しますが、抽出自体には影響しません。
従業員の税務識別番号について — AIはその機密フィールドを読み取りますか？
はい、税務識別番号（Steuer-Identifikationsnummer、11桁の永久的な税務ID）は列フィールドとして抽出できます。レポートに必要ない場合は、その列を定義しないだけです。AIは処理後に抽出データを一切保持しません。税務IDを他のシステムと照合する必要があるチーム（例：賃金税証明書（Lohnsteuerbescheinigung）データとHRISの照合）にとっては利用可能ですが、完全に任意です。
これらの証明書の抽出精度はどのくらいですか？
賃金税証明書（Lohnsteuerbescheinigung）の番号付きフィールドのような印刷された表データの場合、認識精度は最大99%に達します。明確なラベルと予測可能な形式（通貨額、税務ID、日付）を持つフィールドは、この範囲の高水準で抽出されます。形式が変動するフィールド — ヘッダー部分の雇用主名や住所など、行をまたいで異なる方法で折り返される可能性があるもの — は精度が低くなりますが、それでも高い水準です。実務上の推奨事項：他の自動データ抽出と同様に、レポートにデータを使用する前に、出力の最初の数行を元のPDFと照合してスポットチェックしてください。
これは私の税理士（Steuerberater）や給与ソフトウェアを置き換えるものですか？
いいえ。税理士（Steuerberater）や給与ソフトウェアは、法的に義務付けられた給与計算（総額から手取り額への計算、税金の源泉徴収、毎月の賃金税申告（Lohnsteueranmeldung）の提出、電子賃金税証明書（Lohnsteuerbescheinigung）の税務署（Finanzamt）への送信）を実行します。データ抽出はその後に起こること、つまり確定した証明書データを国際的な報告システムに取り込むことを処理します。これは下流のステップであり、上流のコンプライアンス業務を置き換えるものではありません。
同じ方法でドイツの月次給与明細書からデータを抽出できますか？
はい。列名抽出方法は、月次の給与明細書（Gehaltsabrechnung）および賃金明細書（Lohnabrechnung）の文書でも機能します。給与明細からExcelへデータを抽出する必要がある場合、ワークフローは同じです：給与明細書のPDFまたはスキャンをアップロードし、必要な列（純給与（Nettoverdienst）、賃金税（Lohnsteuer）、社会保険料（Sozialversicherungsbeiträge））を定義し、エクスポートします。同じ抽出エンジンが月次給与明細書と年次証明書の両方を処理します。税管轄をまたぐ文書の場合、税務フォームのOCR抽出は、W-2、1099、その他の国固有の税務文書でも同じように機能します。
証明書がファイルキャビネットではなくデータパイプラインに属する理由
賃金税証明書（Lohnsteuerbescheinigung）は、すべての数字が確定し、税務署（Finanzamt）と照合され、法的拘束力を持つ唯一のドイツの給与文書です。月次給与明細書は暫定的なものです。給与システムのCSVエクスポートはデータベーススキーマを反映しており、税の照合を反映していません。証明書は独自の位置を占めています：それはコンプライアンス文書であり、その正確性が法律で保証されているデータソースでもあります。
現在、証明書をコンプライアンスの成果物として扱っているチーム（税理士（Steuerberater）が送信した後にファイルに保管するだけのもの）にとって、見逃している機会は、年間で最もクリーンな給与データセットです。50枚の証明書には、ドイツの従業員に関する500以上の照合済みデータポイントが含まれており、税務当局の記録に対してすでに検証されています。唯一の疑問は、それらのデータポイントがスプレッドシートに反映されるか、PDF内に閉じ込められたままになるかです。