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条は特定のメカニズムを定めています。解雇（rescisão）時に、雇用主が支払うべき全額（過去の過少支払い分の修正額を含む）を支払わなかった場合、従業員はその差額の2倍を受け取る権利を得ます。1人の人事担当者が月に50枚のホレリッチを手入力する環境では、エラー率は保険数理上の確実性です。給与計算における手動データ入力の研究では、通常1%から3%のエラー率が見られます。つまり、1,200枚のホレリッチのバッチでは、12から36行に少なくとも1つの誤った値が含まれていることになります。

バッチ処理アプローチが異なるのは、エラーを完全になくすからではありません — どんな抽出方法でも、あらゆる文書品質に対して100%の精度を達成できるわけではありません。変わるのは、エラーをいつ発見するか、そして一度にいくつ発見できるかです。

手動ワークフローでは、各ホレリッチは独立した検証単位です。値を入力し、給与明細を見て、次のものに移ります。行をまたいだ整合性チェックはありません。同じ給与帯の14人の従業員に影響するINSSの税率区分の誤分類は、手動フローでは14件の独立したミスのように見え、何ヶ月も気づかれない可能性があります。

バッチワークフローでは、統合された出力により、行をまたいで異常を可視化できます。INSS拠出金列を降順で並べ替えます。同じグロス給与の従業員は、同一のINSS控除額（累進税率区分計算で調整済み）になるはずです。R$3,000帯の従業員14人のうち12人が約R$219（最初の2つの税率区分を累進適用）の正しいINSSを示し、2人がR$240を示している場合、調査が必要な2行を特定できます — 14回の個別チェックではなく、1回の並べ替え操作でです。

バッチ処理が月末締めをどう変えるか

複数のクライアントを抱える会計事務所（escritório de contabilidade）の場合、月末の給与締めは次のような順序で行われます。各クライアントの給与システムからホレリッチPDFを受け取る → 手動キー入力または主要項目を会計ソフトにエクスポートする → DARF/GFIPの集計と照合する → eSocialのS-1299月次クロージャイベントを提出する → クライアントレポートを作成する。バッチ抽出は、中間の2つのステップを、数日かかるデータ入力プロセスから、1回の抽出と確認のセッションに圧縮します。

変わるのはスピードだけではありません。30社分の給与データがPDFの中ではなく構造化フォーマットで存在することで可能になることこそが本質です。「従業員1人あたりの平均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 RMで「INSS Contribuição」とラベル付けされた給与明細、ADPブラジルで「Previdência INSS」と表記されたもの、セニオール・システマスで「Desconto INSS」と書かれたものも、すべて同じ出力列にマッピングされます。これは、AIがラベルの意味を理解するためです。これがテンプレートOCRに対する根本的な利点です。つまり、列を一度定義すれば、あらゆるソース形式が同じ構造に解決されます。

バッチ処理中に計算列を使用してINSSとIRRFを検証できますか？

はい。累進課税方式を使用して、抽出されたグロス給与から期待されるINSSを計算する計算列を定義できます。例えば、「INSS Expected (Progressive Calc)」という名前の列に、グロス給与に4つのINSS税率区分を適用する計算ルールを設定すると、期待される控除額が生成されます。これを抽出された「INSS拠出金」列と比較し、2つの値が異なる行はレビュー対象としてフラグが立てられます。出力スプレッドシートから離れることなく、バッチ内監査を実現します。

バッチ出力にはソースファイル名が含まれ、各行を元の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に抽出するガイドから始めてください。その後、同じプロセスを給与全体で一度に1バッチずつ実行する準備ができたら、こちらに戻ってきてください。