給与明細(ホレリッチ)50枚、
給与サマリー1つに
サンパウロの会計事務所が30社のクライアント企業の給与を処理しており、毎月約1,200枚のホレリッチを処理しています。それぞれ異なる雇用主、異なる給与システム、異なるPDFレイアウトで生成されています。ボトルネックは抽出技術ではありません。50枚目のホレリッチの抽出が終わった瞬間、全従業員のINSS合計が雇用主のDARF(連邦歳入徴収書)納付額と一致せず、どの行が間違っているのか分からない——その時点が問題なのです。

重要ポイント
- ホレリッチの手入力に月40時間以上かかるのは遅いだけではありません。手入力エラー率1〜3%では、1,200行のバッチで統計的に12〜36件の誤ったINSSまたはIRRF値が発生し、元従業員の弁護士が気付くまで見つからないのです。
- CLT第467条は、解雇時に発見された未払金をすべて2倍にします。また、1行ずつデータを入力しても全従業員の控除を並べて確認できないため、修正されないエラーは静かに累積していきます。
- ImageToTable.aiは、あらゆる給与システムのホレリッチ50〜1,200枚を1回のバッチアップロード、1つの定義済み列セット、1つの統合スプレッドシートにまとめます。その後、1回の列ソートで全従業員の控除異常が検出され、40時間のデータ入力作業が15分の監査に変わります。
1件ずつの給与明細抽出がスケールしない理由

ブラジルの給与明細(ホレリッチ/コントラシェッキ)を1枚Excelに抽出すれば、1人の従業員のデータに関する疑問は解決します。しかし、会社全体の答えが必要になった瞬間——INSS負担額の合計、FGTS預金の総額、給与帯別の平均IRRF源泉徴収額——単一ファイルの抽出はワークフローではなくなり、スローモーションのデータ照合作業に変わります。
すでにINSSとIRRFを含むブラジルの給与明細をExcelに抽出するガイドをお読みの方は基本をご存じでしょう:列名を定義し、ホレリッチPDFをアップロードし、AIがラベルの意味を理解して各フィールドを抽出します(画面上の位置ではありません)。これは1枚の給与明細には有効です。しかし、12社の異なる会社から50枚のホレリッチがある場合、課題は1件ずつのワークフローでは対応できない3つの構造的な形に変わります。
第一に、マルチフォーマットの不整合。30社のクライアントを抱える給与アウトソーシング業者は、30枚の同一PDFを受け取るわけではありません。TOTVS RMはあるレイアウトでホレリッチを生成し、ADPブラジルは別のレイアウト、セニオール・システマスはまた別のレイアウトです。小規模企業のクライアントからは、印刷された給与明細のスマホ写真——サーマル紙、かすれたインク、機械可読データ層なし——を渡されることもあります。1件ずつのワークフローでは、各フォーマットに手動で対応します。バッチワークフローでは、ツールが再設定なしで全フォーマットを同時に処理する必要があります。セマンティック抽出——固定座標の一致ではなくラベルの意味を理解して「INSS」を見つけること——が、バッチ処理と問題のバッチ化の違いを生みます。
第二に、照合の負担が倍増する。1枚のホレリッチには4つの法定控除——INSS、IRRF、FGTS、および交通費補助や組合費などの任意控除——があります。1枚の給与明細の控除を公式の税表と照合するのは数秒で済みます。1,200枚のホレリッチの場合、同じ照合はフルタイムの仕事になります。さらに悪いことに、雇用主の月次DARFとGFIP(FGTS納付および社会保障情報ガイド——政令第8.373/2014号に基づきeSocialを通じてDCTFWebに完全移行予定)は、全従業員のINSS/IRRF/FGTS合計を報告します。抽出したバッチ合計が雇用主の集計申告と一致しない場合、どの従業員行がずれているかを特定する必要があります——1,200行の中での検索は、速くもなければ請求可能でもありません。
第三に、コンプライアンスリスクは加算ではなく増幅される。CLT第467条に基づき、雇用主が賃金控除を過少納付した場合——例えば誤ったINSSまたはIRRF額を報告した場合——その不足が退職時に発覚すると、従業員は不足額の2倍を受け取る権利があります。1人の従業員、1ヶ月の場合、財務的エクスポージャーは痛いですが限定的です。12ヶ月にわたる50人の従業員の場合、単一の系統的エラー——例えば、IRRF控除を1つの税率帯で過少計算する給与ソフトウェアの設定ミス——が600のデータポイントにわたって累積します。バッチワークフローは抽出を速くするだけではありません。ブラジル連邦歳入庁の累進税率表に対して600
バッチワークフロー — ホレリッチ50枚を1枚の給与シートに

バッチワークフローは、入力の多様性と出力の一貫性の関係を逆転させます。50枚のホレリッチが8つの異なる給与システム、8つの異なるPDFレイアウトから来ることを受け入れつつ、すべての行がまったく同じ列構造に従う1つのスプレッドシートを作り出します。
これを可能にする仕組みがカスタム列抽出です。各ドキュメントの各フィールドにバウンディングボックスを描く必要があるテンプレートベースのOCRとは異なり、カスタム列抽出は意味的に機能します。「グロス給与」「INSS拠出金」「IRRF控除」「FGTS預金」「ネット給与」など、必要なフィールド名を入力するだけで、AIがラベルの意味を理解して各ドキュメント上の対応する値を特定します。「INSS Contribuição」とラベル付けされたTOTVSのホレリッチも、「Previdência INSS」とラベル付けされたADPのホレリッチも、AIが座標ではなく意味を読むため、同じ出力列に解決されます。
実際のバッチワークフローの流れは次のとおりです。
ファイルは安全に処理され、保存されることはありません。
バッチ処理はファイル名を気にしません。 手動のExcelワークフローでは「Holerite_Joao_Maio.pdf」のようにファイル名を付けてデータの出所を追跡しますが、バッチ処理では出力に元のファイル名が保持されます。給与システムがエクスポートした名前のままファイルをアップロードでき、出力スプレッドシートには「ソースファイル」列があり、すべての行の出所を追跡できます。
バッチの照合 — 抽出された合計をDARF、GFIP、eSocialと照合する

スプレッドシートが届きました。1,200行。30クライアントにわたる50名の従業員。CNPJでフィルタリングし、グロス給与帯で並べ替え、参照月ごとにINSS控除をピボットできます。しかし、それを信頼する前に、ひとつの問いに答えなければなりません。AIが抽出した合計は、雇用主が報告した内容と一致するでしょうか?
毎月、ブラジルの雇用主は総給与に基づいて3つの納税申告を行います。
- DARF Previdenciário — 全従業員分のINSS納付をまとめたもので、翌月20日までに納付します。DARF上のINSS合計額は、バッチ出力に含まれる各従業員のINSS控除額の合計に、事業主負担分である20%のINSS事業主拠出金を加えた額と一致する必要があります。この事業主負担分は雇用主の会計記録には計上されますが、個々のホレリッチには表示されません。
- FGTS via GFIP and now DCTFWeb — 各従業員のグロス給与に対する8%の雇用主預託金で、法律第8.036/1990号に基づき、翌月7日までにカイシャ・エコノミカ・フェデラルを通じて納付します。GFIP/DCTFWeb上のFGTS合計額は、バッチ出力の各従業員のFGTS額の合計と一致する必要があります。FGTSは累進課税のない一律8%であるため、これは常に一致するはずです。
- IRRF via DARF — 全従業員から源泉徴収された所得税の合計額です。これは照合が最も難しい項目です。各従業員のIRRFは累進的に計算され、扶養家族1人につき月額R$189.59の控除があり、法律第15.191/2025号により非課税限度額がR$2,259.20からR$2,428.80に引き上げられた2025年半ばに税率区分が変更されたためです。
照合ステップ自体は、データがExcelに入ってしまえば迅速です。各控除列の下部にSUM列を追加してください。INSS合計額をDARFのINSS額と比較します。FGTS合計額をGFIPの値と比較します。数値が一致すれば — 抽出が正確で、雇用主の給与計算が正しく設定されていれば一致するはずですが — eSocialへのクロス提出に備えた検証済みデータセットが完成します。
数値が一致しない場合、統合スプレッドシートは数学の問題ではなく調査ツールになります。従業員で絞り込み、ネット給与の降順で並べ替え、各従業員のIRRF値をブラジル連邦歳入庁の累進税率表と比較します。1,200行のスプレッドシートでの15分の監査は、個々のホレリッチPDFを開いて控除を手作業で再確認する数時間の作業に取って代わります。
CLT第467条の罰則と規模の影響 — バッチ処理で1桁の入力ミスがなぜ拡大するのか
ブラジルの労働法は、雇用主が発見した給与計算エラーと、従業員の弁護士が発見したエラーを区別しません。控除額が誤っている場合 — 原因が給与ソフトウェアのバグ、税率区分の誤分類、手動データ入力ミスのいずれであっても — 責任の時計はエラーが発生した瞬間から動き始めます。発見した時点からではありません。
CLT第467条は特定のメカニズムを定めています。解雇時に雇用主が未払い額全額(過去の過少支払いの修正額を含む)を支払わない場合、従業員は差額の2倍を受け取る権利があります。1人のHRアナリストが毎月50枚のホレリッチを手入力する環境では、エラー率は保険数理上確実です。給与計算における手動データ入力の調査では、一般的にエラー率は1%〜3%とされています。つまり、1,200枚のホレリッチのバッチでは、12〜36行に少なくとも1つの誤った値が含まれることになります。
バッチ処理アプローチが異なるのは、エラーを完全に排除するからではありません — どの抽出方法も、あらゆる文書品質に対して100%の精度を達成できるわけではありません。変わるのは、エラーをいつ発見するか、そして一度にいくつ発見するかです。
手動ワークフローでは、各ホレリッチは独立した検証単位です。値を入力し、給与明細を確認し、次のものに進みます。行間の整合性チェックはありません。同じ給与帯の14人の従業員に影響するINSS税率区分の誤分類は、手動フローでは14件の独立したミスのように見え、数か月間気づかれない可能性があります。
バッチワークフローでは、統合された出力により、行全体で異常が可視化されます。INSS拠出金の列を降順に並べ替えます。同じグロス給与の従業員は、同一のINSS控除額(累進税率区分計算に基づき調整済み)であるべきです。R$3,000帯の14人の従業員のうち12人が正しいINSS約R$219(最初の2つの税率区分を累進適用)を示し、2人がR$240を示している場合、調査が必要な2行を特定できます — 14回の個別チェックではなく、1回の並べ替え操作で。
手動バッチ給与計算の本当のコストは、データ入力に費やす40時間ではありません。それは、全従業員の控除を並べて一覧表示する手段がなかったために未検出のまま残るエラーの複利的責任です。バッチ抽出は、給与計算の検証を文書ごとの作業から列ごとの監査へと変えます — これこそが、バッチ処理を単に速くするだけでなく、より安全にする運用上の違いです。
バッチ処理が月次決算にもたらす変化
複数のクライアントを抱える会計事務所(escritório de contabilidade)における月次給与決算は、以下のような決まった流れで進みます。各クライアントの給与システムからホレリテPDFを受領 → 主要項目を手動で会計ソフトに入力またはエクスポート → DARF/GFIP集計と照合 → eSocial S-1299月次クローズイベントを送信 → クライアント向けレポートを作成。バッチ抽出により、このうち中間の2ステップが、数日かかるデータ入力プロセスから、1回の抽出・確認セッションに短縮されます。
変化はスピードだけではありません。30社分の給与データがPDFではなく構造化形式で存在することで、新たな可能性が広がります。「従業員一人当たりの平均INSS負担が最も高いクライアントはどこか」「第1四半期と第2四半期で、どの給与帯のIRRF源泉徴収額が最も増加したか」といった質問に、数百枚のホレリテを読み直すのではなく、スプレッドシートをフィルタリングするだけで答えられるようになります。
給与明細と仕入先請求書の両方を処理する企業(同じクライアントに対して給与計算と買掛金管理を担当する会計事務所に多いケース)では、同じバッチ手法が文書タイプを問わず適用できます。ブラジルのNF-e請求書データをバッチ抽出する仕組みも同じ原理に基づいています。列を一度定義し、すべてをアップロードし、1つのスプレッドシートを取得する。入力がホレリテでもDANFEでもNF-e XMLでも、出力形式は同じです。
ほとんどの給与チームがバッチ処理に切り替えるのは、データ抽出を高速化したいからではありません。手動で入力された給与データは決して監査されないことに気づくからです。単に時間がないのです。バッチ抽出により、監査が例外ではなく標準になります。数値を確認するために必要なデータが、数値自体と同じスプレッドシートにすでに存在するからです。
よくある質問
1回のバッチで処理できるホレリテの数は?
バッチあたりのファイル数に厳格な上限はありません。ツールは単一のキューでファイルを順次処理します。30以上のクライアントを抱える会計事務所の場合、特定の月の全ホレリテ(1,200ファイルでも)を1回のバッチでアップロードできます。出力は1つのExcelファイルに統合され、CNPJや会社名でフィルタリングしてクライアントを分けることができます。非常に大規模なバッチの場合、技術的なアップロード上限ではなく、プランの月間ファイル割り当てが制約となります。
異なる雇用主が「INSS」や「Previdência」など異なるフィールド名を使う場合は?
AIは意味的に抽出するため、PDF上のラベル表記に関わらず「INSS拠出金」という概念に該当する値を見つけます。TOTVSの給与明細で「INSS Contribuição」、ADPで「Previdência INSS」、Seniorで「Desconto INSS」と表記されていても、AIがラベルの意味を理解するため、すべて同じ出力列にマッピングされます。これがテンプレートOCRに対する根本的な利点です。列を一度定義すれば、すべてのソース形式が同じ構造に解決されます。
バッチ処理中に計算列を使ってINSSやIRRFを検証できますか?
はい。累進課税方式を使用して、抽出された総支給額から期待されるINSSを計算する計算列を定義できます。例えば、「INSS期待値(累進計算)」という列に、総支給額に4つのINSS区分を適用する計算ルールを設定すると、期待される控除額が生成されます。これを抽出された「INSS拠出金」列と比較し、値が異なる行はレビュー対象としてフラグが立てられます。出力スプレッドシートから離れることなく、組み込みのバッチ監査が可能です。
バッチ出力にはソースファイル名が含まれ、各行を元のPDFにトレースできますか?
はい。出力の各行には、どのアップロード済み文書がその行を生成したかを示す「ソースファイル」列が含まれます。これはコンプライアンスワークフローに不可欠です。監査人が特定の月の特定の従業員のホレリット(給与明細)を要求した場合、PDFフォルダを検索する代わりにスプレッドシートをフィルタリングすることで、ソースファイルを即座に見つけることができます。
50枚のホレリットのバッチで1枚の抽出に失敗した場合はどうなりますか?
バッチ処理は継続されます。1つのファイルの失敗で残りが停止することはありません。処理後、問題のあったファイルを確認できます(通常、極端な画質問題によりAIがフィールドを見つけられなかった場合にフラグが立てられます)。その後、それらのファイルのみを小さなフォローアップバッチで再アップロードできます。給与計算ソフトウェアで生成され、構造化されたレイアウトを持つブラジルの給与明細PDFの大半では、バッチ間での抽出信頼性は一貫して高いです。
これは、TOTVSやADPのような給与計算ソフトの代わりになりますか?
いいえ。給与計算ソフトは控除額の計算、ホレリチ(給与明細)の作成、eSocial提出用ファイルの生成を行います。バッチ抽出は、ワークフロー上では給与計算ソフトの後に位置します。つまり、給与システムがすでに生成したPDFを取得し、分析、顧客間の統合、コンプライアンス検証のための構造化データに変換し直します。給与計算エンジンを置き換えるのではなく、「ホレリチのPDFがある」状態から「従業員、月、顧客を横断して給与データを分析できる」状態へのギャップを埋めるものです。
単なるエクスポートではなく、監査です
50枚のホレリチを手作業でExcelに入力すれば、スプレッドシートができます。50枚のホレリチをバッチ抽出しても、スプレッドシートができます。違いはファイル形式ではありません。違いは、一方のスプレッドシートには注意深く入力したから正しいはずだと願う値が入っているのに対し、もう一方には、同じ列で従業員間の監査ができるため検証可能な値が入っていることです。
ブラジルの給与計算には、INSSに4段階の累進税率、IRRFに5段階、一律のFGTS率、そして事業主負担分の20%のINSS拠出があり、単一の一律給与税しかない国と比較して、調整の対象範囲は3倍になります。この複雑さを1枚のホレリチずつ処理するのは、従業員が5人なら許容範囲です。50人では持続不可能です。1,200人では危険です。なぜなら、CLT第467条に基づく未発見のエラーのコストは未払い額の2倍であり、これだけ大規模なバッチでは、手動データ入力のデフォルトの状態は「未発見」だからです。
単一ホレリチの基本(INSSの累進税率、給与帯別のIRRF源泉徴収、FGTSの仕組み、抽出フローのステップバイステップ)については、まずブラジルの給与明細データをExcelに抽出するガイドをご覧ください。その後、同じプロセスを給与全体に一度に一括適用する準備ができたら、こちらに戻ってきてください。