寄付者レター300通、税務サマリー1つに
再入力なしの年末寄付明細書

12月から1月の追い込み：300通の手紙と31日間の時計

12月31日は、その年の税控除の対象となる寄付の最終暦日です。12月30日消印の小切手、12月31日に請求されるクレジットカード、12月最終週に開始された株式移転——すべて有効です。そして、それらすべてが1月の最初の2週間に開発チームの机に届くお礼状を生み出し、11月の寄付からすでにキューに入っている手紙に加わります。その結果、Blackbaudの2025年Trends in Givingレポートがセクターレベルで捉えている量の急増が発生します。典型的な非営利団体は、年間収入の3分の1以上を第4四半期に受け取ります。年間300件の寄付者ギフトを処理する組織にとって、それは1月だけで約100通のお礼状をまとめることを意味します——さらに、各寄付者の年間贈与履歴を1つの明細書に集計する作業も加わります。

IRSの期限は構造的な緊急性を加えます：非営利団体は、IRS Publication 1771に従い、翌年の1月31日までに年末の寄付者明細書を提供することが期待されています。これは申告期限ではなく、寄付者の期待に応える期限です。2月初めに税申告書を提出する寄付者は、明細書が手元にあることを期待しています。明細書が遅れると、寄付者の不満、繰り返されるフォローアップメール、そして最悪の場合、控除を立証できない寄付者につながります。

しかし、核心的なボトルネックは期限ではありません。それはソース資料の形式の多様性です。一部のお礼状は、CRMによって自動生成されたきれいなPDFとして存在します。他は、複数寄付の要約がインラインで貼り付けられた転送されたメールスレッドです。さらに他は、手書きの寄付者メモが付いたスキャンされた紙の手紙、または募金イベントで記入された現物贈与のお礼フォームです。それぞれに同じ必須データ——寄付者名、贈与日、金額、贈与タイプ——が含まれていますが、同じ形式で届くものは2つとしてありません。300件をスプレッドシートに手入力するのがデフォルトであり、そのデフォルトは、1月にはない開発チームの丸々1週間の労働時間を費やします。

IRSが年末寄付明細書に実際に求めるもの

バッチ抽出ワークフローを構築する前に、最終的にどのようなデータが必要になるかを明確にしておく価値があります。IRSは寄付者への受領確認書の形式を規定していません。手紙、はがき、コンピューター生成のフォームのいずれも有効です。IRSが義務付けているのは内容です。

内国歳入法第170条(f)(8)およびIRS Publication 1771に基づき、250ドル以上の単一の寄付に対する同時期の書面による受領確認書には、以下を含める必要があります：

• 慈善団体の名称
• 現金寄付の金額
• 現金以外で寄付された財産の説明（評価額は不要）
• 団体が寄付の対価として物品またはサービスを提供したかどうか、および提供した場合はその公正市場価値の誠実な見積もりに関する記載

250ドル未満の個別の寄付は、250ドルの基準額に達するために合算されることはありません。教会で毎週50ドルを寄付し、年間合計2,600ドルになる場合でも、個々の寄付が250ドルに達しない限り、正式な受領確認書は不要です。とはいえ、ほとんどの非営利団体は、寄付者サービスとして、またIRSのガイダンスに従い、単一の年間サマリーで複数の250ドル以上の寄付を裏付けることができるため、規模に関係なくすべての寄付をカバーする年末サマリーを送付しています。

現金以外の寄付については基準が上がります：500ドルを超える寄付にはIRS Form 8283を寄付者の確定申告に添付する必要があり、5,000ドルを超える現金以外の寄付には通常、適格な鑑定が必要です。バッチ抽出の出力が寄付者明細書に反映される場合、どの寄付がこれらの基準を超えるかをフラグ付けする必要があります。これは「非現金価値」というラベルのスプレッドシート列と、「Form 8283必須」というラベルの2番目の列で簡単に処理できます。

重要なポイント：IRSが受領確認書ごとに求めるデータ項目は比較的少なく、これはまさにテンプレート不要のバッチ抽出が手動入力を上回るシナリオです。あなたは手紙を転記しているのではありません。各ページから5〜6個のデータポイントを抽出しているのです。

CRMの自動生成では半分しか解決できない理由

ほとんどのドナー管理プラットフォーム（Blackbaud Raiser's Edge NXT、Bloomerang、DonorPerfect、Salesforce NPSP、Little Green Light）は、データベースにすでに登録されている寄付記録から年末の寄付明細書を自動生成できます。ドナーが組織の統合された寄付フォームを通じてオンラインで寄付した場合、CRMには金額、日付、ドナーの連絡先情報が記録されています。その経路については、自動マージは解決済みの問題です。

ギャップが生じるのは、寄付がCRMに自動的に反映されないチャネルを通じて組織に入る場合です。

• 事務所に郵送された小切手。開発アシスタントが封筒を開け、小切手を銀行の入金記録に記帳し、同封の手紙をファイルします。CRMが同じ日に更新されない場合、またはCRMの入力がキャンペーンを指定する小切手のメモ欄を省略した場合、その寄付は謝礼状には記載されても、ドナーのCRM記録には反映されません。
• イベント寄付と寄付誓約。募金ガラでは80枚の寄付誓約カードが作成され、それぞれに手書きの金額、ドナーの署名、支払い方法が記入されます。それらのカードはスキャンされて開発部門にメールで送られます。CRMにはイベントの一括入金が見えますが、個々の誓約の内訳は見えません。
• ドナー助言基金（DAF）の助成金。DAFスポンサーが助成金の小切手を送付します（多くの場合、ドナーの特定情報は最小限です）。非営利団体は、その助成金をCRM内の一致する誓約と照合する必要があります。DAFスポンサーからの謝礼状が、金額と助成ドナーの両方の信頼できる情報源です。
• 現物寄付。地元企業が5,000ドル相当のオークション品を寄付します。謝礼状には品目が記載されていますが、金額は割り当てられていません。CRMには寄付が記録されますが、実際の裏付けとなる文言は謝礼状から得られます。
• 第三者寄付プラットフォーム。Facebook Fundraisers、Benevity、Network for Good、職場寄付ポータルは、それぞれ独自の謝礼形式を生成します。一部は統合を通じてCRMに反映されますが、多くは月次の要約PDFとして届きます。

いずれの場合も、謝礼状は存在します（IRS準拠の記録です）が、その中の構造化データは、年末の統合に必要なスプレッドシートには反映されていません。問題は「CRMを使うべきか」ではなく、「CRMが生成しなかった謝礼状からデータを同じドナーサマリーに取り込むにはどうすればよいか」です。

謝辞レターから統合税務サマリーへ：バッチ抽出ワークフロー

ここでバッチファースト文書抽出が1月の計算を変えます。各レターを開いて、寄付者名、寄付日、金額を読み取り、それらの値をスプレッドシートの行に入力する代わりに、300通すべてのレターを一度にアップロードします（PDF、スキャン画像、転送されたメールのスクリーンショット、手書きの誓約カードの写真など）。そして抽出したい列を定義します。AIは各レターを意味的に読み取り（「寄付者名」や「寄付金額」がページ上のどこに表示されていても理解し）、すべての謝辞を1行ずつ含む単一のスプレッドシートを出力します。

このワークフローは、開発アシスタントがトレーニングなしで実行できるほどシンプルです：

従来のOCRと異なるのは、抽出モデルです。従来のOCRツールは、ページ上の固定位置から文字を1文字ずつ読み取ります。そのため、CRM生成のPDF、スキャンした紙の手紙、スマートフォンで撮影した誓約カードの間で領収書の形式が変わると機能しなくなります。ImageToTable.aiはカスタム列抽出を使用します。「寄付者名」「寄付金額」「キャンペーン」など、必要なフィールド名を入力すると、AIはページ上の座標を照合するのではなく、意味を理解して各値を特定します。CRMのPDFの上部にある寄付者名も、転送されたメールの下部にあるものも、誓約カードに手書きされたものも、AIがすべて「寄付した人」だと理解するため、同じ列に解決されます。これは、複数ファイルのバッチ処理ガイドで説明したのと同じバッチファースト処理のアーキテクチャであり、200件のACORD 27保険証明書を1つのコンプライアンスダッシュボードに処理する際にも使用しているのと同じアプローチです。

複数の贈与を1つのドナー記録にまとめる（明細書ごと）

バッチ抽出では、領収書ごとに1行が生成されます。しかし、年末のドナー明細書では、暦年内のすべての贈与を集計した、ドナーごとの単一レコードが必要です。Jane Smithさんが3月にFacebook経由で$100、7月に小切手で$250、12月のガラで$500を寄付した場合、3通の領収書から3行が生成されます。年末の明細書では、合計$850の1行が必要です。

バッチ抽出からエクスポートしたスプレッドシートを使えば、この統合は簡単です：

ドナー名の一致が重要なポイントです。CRM生成のPDFに「Jane A. Smith」と記載され、イベントの誓約カードに「Jane Smith」と記載されている場合、Excelの統合で1人のドナーが2行に分割される可能性があります。解決策は、統合前にドナー名列を簡単に確認することです。または、1年分の寄付レターを処理する組織では、推論列を使用して「ドナー名（姓名に標準化）」のような列で抽出することで、AIが抽出時に名前の形式を正規化します。推論列を使用すると、抽出時にルールを指定できます — 「ページ上の内容を抽出する」だけでなく、「抽出してこの形式に標準化する」ことができます。バッチの年末ワークフローでは、これによりエクスポート後のクリーンアップ作業が不要になります。

現物寄付、イベントチケット、非標準的な寄付の処理

上記のバッチ抽出ワークフローは、曖昧さのない通常の現金寄付を処理します。以下の3つのカテゴリの寄付には、少し異なる列定義が必要です：

バッチ抽出の利点は、現物寄付とイベントチケットで最も顕著です。これらはCRMが自動処理する可能性が最も低い領収書タイプであり、データフィールドが標準的な寄付フォームにきれいにマッピングされないためです。各タイプに定義された列（計算列としての「控除可能額（支払総額−FMV）」）を使った単一のバッチ抽出で、現金寄付と同じパスで処理できます。計算列を使用すると、抽出中に算術関係を定義できます。「支払総額」と「FMV」を別々に抽出して後でExcelで減算する代わりに、控除可能額（支払総額−FMV）を列名として定義すると、AIが各イベントチケット領収書を読み取る際に計算を実行します。

寄付者への明細書を送る前に確認すべきこと

自動化により、ボトルネックはデータ入力からデータ検証へと移ります。これは望ましい方向です。300通の謝辞レターを手入力すると、タイプミスと検証疲れの両方が発生します（150通目あたりで、誰も金額を再確認しなくなります）。バッチ抽出なら、自分のタイピングを検証するのではなく、スプレッドシートを検証することになります。

「送信」を押す前に、3つの検証パスを実行してください：

1. 寄付者数の照合。出力スプレッドシートのユニークな寄付者数は、同じ期間のCRM上の寄付者数と一致していますか？不一致があれば、抽出漏れ（AIが解析できなかったレター）や重複レコードの調査が必要です。
2. 入金記録との寄付総額の照合。「現金金額」列を合計してください。会計年度の会計システムに記録された入金総額と一致しますか？銀行の入金合計はクリーンな管理値です。形式や寄付者の身元に関係なく機能します。
3. 外れ値のスポットチェック。金額の降順で並べ替え、上位10行と下位10行を手動で確認してください。最も高額な3件の寄付と、寄付者にとって不自然に見える金額の行（年間50ドルの寄付者が5,000ドルを寄付しているなど）は、元の謝辞レターと照合して目視確認します。

この検証モデル（管理値合計と外れ値レビュー）は、会計照合の標準的な手法であるバッチ処理による財務文書処理から借用したものです。違いは、抽出では自分のキーストロークではなくAIの出力を検証する点です。つまり、エラーが発生する場合、それはランダム（147通目のタイプミス）ではなく、系統的（特定の形式のすべてのレターで一貫して誤るフィールド）である傾向があります。系統的エラーは発見も修正も容易です。

FAQ

AIは誓約カードに手書きされた寄付金額を読み取れますか？

はい。抽出エンジンの基盤となるビジョンモデルは、印刷テキストに加えて手書きテキスト（筆記体、活字体、混在形式を含む）を読み取ります。寄付者名がタイプされ、金額欄に手書きで「$250」と記入された誓約カードでも、両方を正しく抽出できます。薄い鉛筆書きや特殊な筆跡など読み取りにくい場合は、バッチアップロード前にスキャン済みカードを簡単に目視確認することで、再スキャンが必要なカードを事前に把握できます。

IRSは抽出・編集された寄付者明細書を受け入れますか？

IRSは慈善団体が領収書をどのように作成するかを指定していません。必要な情報（団体名、金額、非現金資産の説明、物品・サービスの記載）が最終文書に含まれていればよいのです。ここで説明するバッチ抽出出力は、それらの領収書の元データであり、領収書自体ではありません。抽出したスプレッドシートをレターテンプレートに差し込む場合でも、CRMの明細書生成機能にインポートする場合でも、CRMが自社の記録から自動生成する際の参照用として使う場合でも、IRSが重視するのは寄付者が受け取る最終的な領収書であり、それを編集したツールではありません。

キャンペーンごとに領収書の形式が異なる場合はどうなりますか？

フォーマット非依存は、テンプレートベースのOCRに対するセマンティック抽出の核となる差別化要因です。AIは位置（「寄付者名は常にx=100、y=200の座標にある」）ではなく意味（「このページの寄付者名はどれか」）でフィールドを特定するため、CRMエクスポートのPDF、スキャンした紙の手紙、転送されたメールのスクリーンショットを同じバッチで処理できます。形式ごとの設定は不要です。春のガラで年次キャンペーンとは異なる形式の領収書を使用している場合でも、両方を同じアップロードに含めることができます。

寄付レターのバッチ処理にかかる文書あたりのコストは？

処理は消費された抽出ボリュームに基づいて課金されます。300通の年末バッチの場合、処理時間は数分で、出力はすべての寄付者データを統合した単一のスプレッドシートです。年間を通じて複数のキャンペーンで寄付領収書を処理する団体は、随時バッチ処理できます。25〜30通の月次バッチはさらに高速で、年末の統合作業を再抽出ではなくマージステップに抑えられます。各プランの現在の文書あたりの料金は価格ページをご覧ください。

抽出時に現物寄付と現金寄付を自動で分けることはできますか？

はい、可能です。「贈り物の種類（選択肢：現金、現物、有価証券、DAF助成金）」のような列を定義すると、AIが各受領書を読み取り、その内容に基づいて寄付を正しいカテゴリに分類します。これは推論列です。AIは手紙に既存の「贈り物の種類」ラベルを抽出するのではなく、文書の内容に基づいて分類判断を行います。カテゴリの割り当てはバッチ内で一貫しており、出力スプレッドシートを贈り物の種類でフィルタリングすることで数秒で確認できます。