50枚のホレリート、1つの
給与サマリー

1枚ずつの給与明細抽出ではスケールしない理由

ブラジルの給与明細（ホレリテ/コントラシェキ）を1枚ずつExcelに抽出すれば、1人の従業員のデータに関する疑問は解決します。しかし、会社全体の情報——INSS負担総額、FGTS預託金の合計、給与帯別の平均IRRF源泉徴収額——が必要になった瞬間、1ファイルずつの抽出はワークフローではなくなり、スローモーションのデータ照合プロジェクトと化します。

すでにブラジルの給与明細をINSS・IRRF込みでExcelに抽出するガイドをお読みなら、基本はご存知でしょう：列名を定義し、ホレリテPDFをアップロードすれば、AIがラベルの意味を理解して各フィールドを抽出します（画面上の位置ではありません）。これは1枚の給与明細には有効です。しかし、12社の異なる会社から50枚のホレリテがある場合、1枚ずつのワークフローでは対応できない3つの構造的な課題が生じます。

第一に、マルチフォーマットの非一貫性。 30社のクライアントを抱える給与アウトソーシング会社に、30枚の同一PDFが届くことはありません。TOTVS RMはあるレイアウトでホレリテを生成し、ADP Brazilは別のレイアウト、Senior Sistemasはさらに別のレイアウトです。小規模企業のクライアントは、印刷された給与明細のスマホ写真——感熱紙でインクが薄れ、機械可読なデータ層がない——を渡すかもしれません。1枚ずつのワークフローでは、各フォーマットに手動で対応します。バッチワークフローでは、ツールが再設定なしで全フォーマットを同時に処理できなければなりません。「INSS」を固定座標ではなくラベルの意味で見つけるセマンティック抽出こそが、バッチ処理と問題の先送りの違いを生みます。

第二に、照合の負担が倍増する。 1枚のホレリテには、INSS、IRRF、FGTSという3つの法定控除に加え、交通費（vale-transporte）や組合費などの任意控除があります。1枚の給与明細の控除を公的税率表と照合するのは数秒で済みます。しかし1,200枚のホレリテでは、同じ照合がフルタイムの仕事になります。さらに悪いことに、雇用主の月次DARFおよびGFIP（FGTS納付ガイド兼社会保障情報——政令第8.373/2014号によりeSocialを通じてDCTFWebに完全移行予定）は、全従業員のINSS/IRRF/FGTSの総計を報告します。抽出したバッチ合計が雇用主の総計申告と一致しない場合、どの従業員行がずれているかを特定する必要があります——1,200行の中でのその検索は、迅速でも請求可能でもありません。

第三に、コンプライアンスリスクが増幅される（単純に追加されるのではない）。 CLT第467条に基づき、雇用主が賃金控除を過少納付した場合——例えば誤ったINSSまたはIRRF額を報告した場合——その不足が退職時に発覚すると、従業員は不足額の2倍を受け取る権利があります。1人の従業員、1ヶ月分であれば、財務エクスポージャーは痛いものの範囲は限られます。しかし50人の従業員、12ヶ月分では、単一の系統的エラー——例えば、給与ソフトの設定ミスでIRRF控除が1段階低く計算される——が600のデータポイントにわたって累積します。バッチワークフローは単に抽出を高速化するだけではありません。統一された単一データセットを提供し、600すべての値をReceita Federalの累進税率表と一画面で監査でき、系統的エラーが系統的負債になる前に発見できるのです。

バッチワークフロー — 50枚のホレリットを入力し、1枚の給与シートを出力

バッチワークフローは、入力の多様性と出力の一貫性の関係を逆転させます。8つの異なる給与システムから、8つの異なるPDFレイアウトで届く50枚のホレリットを受け入れ、すべての行がまったく同じ列構造に従う1つのスプレッドシートを生成します。

これを実現する仕組みはカスタム列抽出です。各ドキュメントの各フィールドにバウンディングボックスを描画する必要があるテンプレートベースのOCRとは異なり、カスタム列抽出は意味的に機能します。「総支給額」「INSS拠出額」「源泉徴収額」「FGTS預入額」「手取り額」など、必要なフィールド名を入力するだけで、AIがラベルの意味を理解し、各ドキュメント上の対応する値を特定します。「INSS Contribuição」とラベル付けされたTOTVSのホレリットと、「Previdência INSS」とラベル付けされたADPのホレリットは、どちらも同じ出力列に解決されます。AIは座標ではなく意味を読み取るからです。

実際のバッチワークフローの流れは次のとおりです。

バッチの照合 — 抽出合計とDARF・GFIP・eSocialの突き合わせ

スプレッドシートが届きました。1,200行。30社にわたる50名の従業員。CNPJでフィルタリング、総給与帯で並べ替え、INSS控除を参照月でピボットできます。しかし、データを信頼する前に、一つの問いに答える必要があります。AIが抽出した合計は、雇用主が報告した金額と一致するのでしょうか？

ブラジルの雇用主は毎月、総給与に基づいて3つの集約税を納付します。

• DARF Previdenciário — 全従業員の統合INSS支払いで、翌月20日までに納付。DARFのINSS総額は、バッチ出力の各従業員のINSS控除額の合計に、雇用主の20%分（cota patronal）を加えた額と一致する必要があります（雇用主負担分は会計記録に現れますが、個別の給与明細には表示されません）。
• GFIPおよびDCTFWebによるFGTS — 各従業員の総給与の8%を雇用主が拠出し、Lei nº 8.036/1990に基づき翌月7日までにCaixa Econômica Federalに納付。GFIP/DCTFWebのFGTS総額は、バッチ出力の各従業員のFGTS額の合計と一致する必要があります（FGTSは一律8%で累進がないため、常に一致するはずです）。
• DARFによるIRRF — 全従業員から源泉徴収された所得税の総額。最も照合が難しい項目です。各従業員のIRRFは累進計算され、扶養家族1人あたり月額R$189.59の控除があり、2025年半ばにLei nº 15.191/2025により非課税限度額がR$2,259.20からR$2,428.80に引き上げられました。

データが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回の並べ替え操作でです。

バッチ処理が月次決算にもたらす変化

複数のクライアントを抱える会計事務所（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に抽出するガイドをご覧ください。その後、同じプロセスを給与全体に一度に一括適用する準備ができたら、こちらに戻ってきてください。