ドイツの会計ソフト vs AI請求書抽出
月300件の請求書を処理できるのはどちらのワークフローか?
問題はどのツールを使うかではありません。ほとんどのドイツの財務チームはすでにDATEV、Lexware、またはsevDeskを利用しています。本当の分かれ目は、仕入先請求書データをシステムに入力するための、根本的に異なる2つの考え方の間にあります。どちらを選ぶかによって、チームの毎日の作業時間の使い方が変わってきます。
重要なポイント
- DATEVまたはLexwareを利用しているすべてのドイツの財務チームは、同じ暗黙の前提に従っています。つまり、人間がすべての仕入先PDFを確認し、そのフィールドをソフトウェアの入力グリッドに1件ずつ手入力するという前提です。
- Buchhalterの月50〜75時間が、書類を読むだけで消えていきます。これはDATEV、Lexware、sevDeskがそもそも想定していなかった作業であり、すべての請求書が手入力されるまで、本来の会計処理の強みを発揮できないのです。
- ImageToTable.aiは会計ソフトを置き換えるものではありません。上流のギャップを埋め、仕入先PDFを読み取り、DATEV互換のCSVを出力することで、請求書1件あたり10分の手入力が30秒の確認作業になります。
データ取得の2つの哲学:ツール対決ではなく、考え方の違い
ドイツの財務チームで仕入先請求書を処理しているところは、たとえ名前を付けていなくても、データ取得に関する哲学を持っています。それは日々使っているソフトウェアや、新しい仕入先から最初の請求書が届いたときの判断に組み込まれています。
最初の哲学はフォーム優先です。請求書を開き、ページ上の各フィールドを見て、構造化された入力グリッドにマッピングします。ソフトウェアが枠を提供し、それに合う値を探します。DATEV Unternehmen Online、Lexware Office、sevDeskはこの方法で請求書データ入力を処理します。ソフトウェアが何をどこに置くかを定義し、人間が文書のレイアウトとシステムの期待する形式の間のギャップを埋めます。
2番目の哲学はコンテンツ優先です。必要なデータポイントを指定すると、システムが文書内のどこにあっても、その位置ではなく意味を理解して見つけ出します。これがAIセマンティック抽出、つまりカスタム列抽出です。「Rechnungsnummer」「Nettobertrag」「Leistungsdatum」など必要なフィールド名を入力すると、AIが人間のように文書を読み、どの仕入先のレイアウトであっても各値を見つけ出します。
この2つのアプローチは競合する製品ではありません。ワークフローにおけるインテリジェンスがどこにあるかという、競合する前提です。一方では、人間が文書フィールドをソフトウェアの枠に視覚的に照合することでインテリジェンスを提供します。もう一方では、機械が文書のセマンティクスを理解することでインテリジェンスを提供します。月間の時間数で測ると、その実務上の違いは、ほとんどのチームが認識しているよりも大きいものです。
フォーム優先のデータ入力で月に300件の仕入先請求書を処理する企業は、Buchhalterの時間を約50時間費やします。ドイツのBuchhalterのレートで約2,250ユーロの人件費です。同じ量をセマンティック抽出で処理する場合、レビュー時間は約5時間です。月額2,025ユーロの差は、ソフトウェアのコスト差ではありません。ワークフローの哲学の違いです。
ドイツの会計ソフトは実際にどのように請求書データを処理するのか
この比較で何が重要かを理解するには、マーケティングページを見るのではなく、各プラットフォームでデータ入力が実際にどのように行われるかに注目する必要があります。
DATEV Unternehmen Online (DUO) は、Steuerberaterと連携する企業にとって最も一般的な入り口です。DUOにはOCRベースの請求書認識機能が組み込まれており、文書をアップロードすると、システムが主要フィールドを自動的に抽出しようとします。標準的なドイツの請求書レイアウト(Rechnungsnummerが右側に一貫してラベル付けされ、VATの内訳が予測可能な2行の表に従い、仕入先が従来のテンプレートを使用する種類)では、合理的に機能します。制限は範囲です。DUOの認識は標準形式のドイツの請求書に合わせて調整されており、プラットフォームへの直接アクセスが必要です。変則的な書式、スキャン品質の低さ、非ドイツ語のコンテンツを含む請求書は、通常、OCR処理後に手動修正が必要です。DATEV自体は、自動化の深さにおいて専門の抽出ツールより18〜36か月遅れており、そのAI製品の収益は成長しているものの(2024年に€3.7百万)、VC支援のフィンテックに遅れを取るイノベーションのペースを反映しています。
Lexware Office と sevDesk は異なるアプローチを取ります。両方ともAI対応の領収書取り込みを提供しており、モバイルアプリでBelegをスキャンするか、PDFをドラッグ&ドロップすると、システムが取引に割り当て、仕訳カテゴリを提案します。sevDeskの自動転記ルールは、銀行データと文書データを元帳エントリにマッピングできます。しかし、自動化は浅いものです。AIは抽出ではなく分類を行います。実際のフィールドレベルのデータ(Rechnungsnummer、VAT率別のEinzelbeträge、Leistungsdatum)については、画面の片側で請求書を見ながら、ソフトウェアにもう片方で入力している状況です。Lexware Officeは最小限のAI自動化を提供し、sevDeskは領収書の照合を追加しますが、深いフィールド抽出は行いません。両方ともDATEV互換のエクスポートファイルを生成しますが、それはデータが入力された後に限ります。
1,103のドイツ企業を対象としたBitkom調査では、2024年末時点で構造化された機械可読の電子請求書を受信できる企業はわずか45%でした。残りの55%については、仕入先の請求書がPDFやスキャン画像として届きます。これは、会計ソフトウェアのネイティブなデータ取り込みが大規模に処理するようには設計されていなかった形式です。フォーム優先の哲学は、仕入先が協力的な場合に機能します。協力的でない場合、Buchhalterがそのギャップを埋めることになります。
これらのプラットフォームに共通するのは、微妙でありながら影響力のある設計上の前提です。ソフトウェアは構造化された入力を期待しているということです。DATEVはセミコロン区切りとANSIエンコーディングのCSVファイルをインポートします。sevDeskとLexwareは、事前定義されたラベルを持つフォームフィールドを提供します。すべてのプラットフォームは、データが転記ロジックに到達するまでに、誰かが文書を確認し、関連フィールドを特定し、正しいスロットに配置していることを前提としています。問題は、その「誰か」が人なのか機械なのかということです。
これはソフトウェアへの批判ではありません。これは会計ソフトウェアが何をするように設計されているか、そして何を処理するように設計されていなかったかを正確に説明したものです。DATEVの中核的な能力は文書の読み取りではありません。Steuerberaterワークフローによる税務準拠の複式簿記です。sevDeskの中核的な能力は、撮影されたRechnungenからのフィールド抽出ではありません。中小企業向けの最新の請求書発行および支払い追跡インターフェースです。各ツールはそれぞれの仕事をうまく行います。しかし、仕入先のPDFを構造化データに変換する作業は、それらのいずれもが構築された目的の上流に位置しており、その上流のギャップがBuchhalterのカレンダーをデータ入力時間で埋めているのです。
このギャップがなぜ存在し、電子請求書への移行後もなぜ解消されないのか、より深い分析については、ドイツの請求書データ入力がなぜ根強く手作業に依存しているのか、その構造的な理由を解説した記事をご覧ください。
AIセマンティック抽出が同じ問題にどう取り組むか
セマンティック抽出は、ワークフローの逆の端から始まります。フォームを用意して入力を求める代わりに、何を抽出したいかを指定してもらい、その値をレイアウトに関係なくドキュメント内のどこからでも見つけ出します。
実際の運用は次のようになります。列名を定義します:Rechnungsnummer、Rechnungsdatum、Lieferant、Nettobetrag、USt-Betrag(19%)、USt-Betrag(7%)、Bruttobetrag、USt-IdNr、Leistungsdatum。請求書のバッチをアップロードします — MetroからのPDF 10件、地元のHandwerkerから撮影したRechnungen 5件、オランダのサプライヤーからのスキャン文書3件 — するとAIがすべてを一括処理します。各請求書について、テンプレートの位置を照合するのではなく、フィールドが意味的に何を指すかを理解して、要求された各フィールドを特定します。
この背後にある仕組みは、ルールを後付けしたOCRではありません。人間と同じように文書を読むビジョン言語モデルです。「Rechnungs-Nr.」「RG-Nr. 2026-0442」「Invoice #」がすべて同じ概念を指していることを、ラベルや位置がサプライヤーごとに異なっていても認識します。「Netto」という列の下、「19%」の右側にある数字が、標準VAT税率での正味金額であることを理解します — テンプレートが教えたからではなく、文書の構造が人間の読者に伝えるのと同じ方法でその関係性を伝えているからです。
この3つの機能が、会計ソフトのデータ入力と一線を画します:
テンプレート不要の運用。新しいサプライヤーから最初の請求書が届いても、セットアップは不要です。AIは、既存サプライヤーからの50通目の請求書と同じ方法で読み取ります。これはテンプレートベースのOCRとの最大の運用上の違いです:抽出テンプレートのライブラリを構築・保守・更新する必要が一切ありません。これは、請求書スキャンソフトウェアを評価する際に最初にテストすべき点です。
フォーマット非依存の一貫性。同じ列定義が、鮮明なPDF、紙の請求書のぼやけた写真、2022年のスキャン文書、ZUGFeRDハイブリッドファイルのすべてで機能します。会計ソフトのネイティブOCRは通常、最初のカテゴリのみを確実に処理できます。残りは手動フォールバックが必要になります — ここでフォームファーストの考え方が再び前面に出てきます。
抽出時のフィールドレベル計算。これはページ上の情報を見つけるだけにとどまりません。計算列を定義できます — たとえば、Nettobertrag + USt-Betrag = Bruttobetrag が成立するかをチェックし、一致すれば「OK」、不一致なら差額を出力する列です。この検証は抽出中に実行され、Excelでの別途の後処理ステップとしては実行されません。また、ドキュメントの内容に基づいて請求書を分類する推論列も定義できます — たとえば、サプライヤーの識別情報と請求書の説明に基づいてKostenstelle値を割り当てる場合、どちらのフィールドにも「Kostenstelle」という単語が含まれていなくても機能します。
出力は単一の構造化スプレッドシート — CSVまたはExcel — で、指定した列名がそのままヘッダーとなり、DATEVへの直接インポート用にフォーマットされています(セミコロン区切り、ANSIエンコーディング、DD.MM.YYYY日付形式、カンマ小数表記)。Steuerberaterには、すべて手入力した場合と同じファイル構造が届きますが、キーストロークとエラー率は省かれています。
このフィールドレベルのアプローチ — 必要なデータを指定し、AI にその場所を特定させる方法 — は、個々の請求書フィールドのセマンティック抽出がテンプレートベースの OCR と質的に異なる点です。その違いは速度だけではありません。文書レイアウトを考えるのをやめ、データ要件を考えるようになることです。
§14 UStG のフィールド定義から DATEV 対応出力までのこの抽出ワークフロー構築の詳細な手順については、ドイツの Rechnung データを Excel に抽出するガイドをご覧ください。
比較: テンプレートベース入力 vs セマンティック抽出
この比較はソフトウェアブランドの話ではありません。2つのデータ取得モデルの構造的な違い — そして、実際のドイツの買掛金環境において、それぞれがどこで限界を迎えるかについてです。
| 項目 | 会計ソフトのデータ入力 (DATEV DUO、Lexware、sevDesk) | AI セマンティック抽出 (列名抽出エンジン) | 違いが重要となる場面 |
|---|---|---|---|
| 新規仕入先ごとの設定 | 手動:設定不要だが、請求書ごとにすべて手入力。DUO OCR:特殊なレイアウトでは補正トレーニングが必要な場合あり | 設定不要 — 設定なしでどの仕入先からの最初の請求書でも機能 | 毎月3社以上の新規仕入先を追加する場合、テンプレート保守がAP部門の時間を定期的に圧迫する |
| レイアウト変更 | 手動:人間が自然に適応。DUO OCR:仕入先が請求書テンプレートを変更すると再トレーニングが必要になったり、機能しなくなる可能性あり | 自動的に適応 — 位置が変わっても意味に基づいてフィールドを読み取る | 仕入先は平均して年に1〜2回、請求システムやテンプレートを変更する — 変更のたびにテンプレートベースのシステムでは例外処理が発生する |
| 文書形式 | 手動:読み取り可能な形式なら何でも対応。DUO OCR:クリーンなPDFと標準的なレイアウトに最適化 | PDF、JPG、PNG、スクリーンショット、写真、スキャン — 同じエンジンが全形式に対応 | ドイツの中小企業の推定40〜55%は今も非構造化請求書(スキャン、写真、プレーンなPDF)を受け取っている |
| 手書き文字 | 手動:人間の読取担当者は判読可能な手書き文字のほとんどを処理。OCR:手書きフィールドではほとんど失敗 | 判読可能な手書き文字を読み取り;読みにくい走り書きでは、人間の読取担当者が苦労するのと同じように精度が低下 | Handwerker、個人事業主、小規模仕入先は、手書きまたは部分的に手書きのRechnungenを発行することが多い |
| VAT税率分割処理(19% / 7%) | 手動:Buchhalterが各行の正しいSteuerschlüsselを特定して適用。OCR:レイアウトが予測可能なら抽出可能 | 明細行テーブルから分割されたVAT税率を抽出;§13b逆チャージのシナリオも識別可能 | 複数税率の請求書(例:19%と7%の行がある食品卸売業者)は、手入力で最もエラーが多いカテゴリ。Steuerschlüsselの誤適用はUStVA申告の誤りにつながる |
| 多言語請求書 | 手動:人間はどの言語でも読める。DUO OCR:主にドイツ語向けに調整;英語、フランス語、オランダ語のレイアウトでは精度が低下 | ドイツ語、英語、フランス語、オランダ語などを同じバッチで処理 | EU域内の国境を越えた取引により、一般的なドイツの中小企業では仕入先請求書の約15〜25%がドイツ語以外の言語で届く |
| 請求書1件あたりの処理時間 | 手動:請求書1件あたり10〜15分。DUO OCR:2〜5分(非標準レイアウトの補正時間を除く)。sevDesk AI:2〜4分 | 抽出5〜10秒 + 請求書1件あたりの人間によるレビュー30〜60秒 | 月100件の場合:17〜25時間(手動) vs 1〜2時間(AI)。月300件の場合:50〜75時間 vs 3〜5時間。その差は縮まらず、量が増えるほど広がる |
| スケーラビリティ | 線形:請求書が増えるほど、比例して人件費が増加。OCRは傾きを緩やかにするが、平坦にはしない | ほぼ平坦:50件でも500件でもAI処理時間はほぼ比例;レビュー時間は緩やかに増加 | 月100件から300件へ成長する企業は、通常フォームファーストモデルでは人員を追加する。意味ベース抽出では、処理時間が数分増えるだけ |
| DATEV出力 | DUO: ネイティブ統合 — データはDATEVエコシステム内に留まります。Lexware/sevDesk: DATEVエクスポート(CSVまたはEXTF) | セミコロン区切りの構造化CSV、ANSIエンコーディング、DD.MM.YYYY形式の日付、カンマ区切りの小数 — SteuerberaterによるDATEVインポートに対応 | 両方ともDATEV互換の出力を生成します。違いは形式ではなく、その前に行われる人的作業の量にあります |
| GoBD準拠 | 会計ソフトウェアに組み込み: 監査証跡、改ざん防止、10年間のアーカイブ | 抽出ツールは監査ログを提供する必要があります。元の文書 + 抽出データ + ログ = GoBDレコードとしてDMSまたは会計システムで管理されます | GoBDでは、抽出データだけでなく、受領した形式の元の文書が必要です。両方のワークフローで準拠にはDMSが必要です — 抽出ツールはDMSの代替ではありません |
それぞれのアプローチが適している場面
正直な比較には線引きが必要です。どちらのアプローチも普遍的に正しいわけではありません。判断の基準は、取引量、仕入先の多様性、そしてワークフローが実際に受け取る非構造化入力の量です。
ネイティブ会計ソフトのデータ入力が適しているケース: 月間の請求書処理が20〜30件未満で、ほとんどが標準レイアウトの国内ドイツ人仕入先からのもので、Steuerberater が DATEV エコシステム内で全てをエンドツーエンドで処理し、多言語や手書きの入力がない場合です。このシナリオでは、抽出レイヤー(軽量なものでも)を導入するオーバーヘッドが、節約できる時間に見合わない可能性があります。シンプルに保ちましょう。フォームファーストモデルは、まさにこのボリューム向けに設計されています。
AI セマンティック抽出がより有力となるケース: 月間の請求書量が50件を超え、仕入先に混合フォーマット(PDF、スキャン、写真)が含まれ、多言語の請求書を扱い、ヘッダーフィールドだけでなく明細レベルの詳細が必要な場合、または月次決算のために請求書を一括処理する場合です。抽出が費用対効果を発揮する閾値は主観的なものではなく、ドイツのコスト環境向けに構築されたフレームワークを使って計算可能です。詳細はドイツ中小企業向け請求書処理コスト計算フレームワークで説明しています。
多くのチームが辿り着く中間的な方法: 馴染みのある仕入先からクリーンな PDF で届く標準的な国内請求書には DUO を使用し、例外的な書類 — 写真で撮影された Handwerker の請求書、オランダの仕入先の PDF、VAT が分割された複数ページの Metro Rechnungen — には AI 抽出レイヤーを使用します。このハイブリッドアプローチは会計ソフトを置き換えるものではありません。最も労働集約的な書類を最速で処理できるツールに振り分け、単純な書類はネイティブのワークフローに残します。
バッチ抽出が実際にどのようにこれを処理するかについての具体的な手順 — 80件の混合形式のRechnungenを1回のアップロードで処理する例 — は、ドイツのEingangsrechnungenをExcelにバッチ処理するガイドをご覧ください。
DATEVへの受け渡し:ネイティブ統合よりもCSV互換性が重要な理由
ドイツの会計ソフトウェア比較では、「ネイティブなDATEV統合」がCSVベースのデータ受け渡しよりも本質的に優れているという前提がよく見られます。この前提を直接検証する価値があります。
DATEVのインポート形式は厳格かつ明確に文書化されています:区切り文字はセミコロン、エンコーディングはANSI/Windows-1252、日付形式はDD.MM.YYYY、小数点はカンマ表記(1.234,56 €)です。これらの要件を満たすCSVファイルは、DUOのネイティブインターフェースを通じて入力されたデータと機能的に同一です — SteuerberaterのDATEV Rechnungswesenインストールは同じ方法で処理します。インポートインターフェースは、DUOのOCRが生成したCSVと外部抽出ツールが生成したCSVを区別しません。フィールドの順序、エンコーディング、書式規則が一致していれば問題ありません。
統合アーキテクチャよりも重要なのは、Steuerberaterの机に届くCSVのフィールド完全性です。14のPflichtangabenのうち7つだけを抽出し、残りの7つを手動で補完する必要があるネイティブDUO統合は、14のフィールドすべてを正しい形式で、各フィールドに信頼スコアを付けて提供する外部抽出ワークフローよりも有用性が低くなります。SteuerberaterはどのソフトウェアがCSVを生成したかを気にしません。彼らが気にするのは、転記前に修正が必要かどうかです。
これが、抽出ツールのブランド名よりも出力形式が重要である理由でもあります。セミコロンであってカンマではない。ANSIであってUTF-8ではない。DD.MM.YYYYであってISO 8601ではない。カンマ小数点であってピリオド小数点ではない。これらの規則の1つでも間違えると — 多くの汎用抽出ツールが実際に間違えます — DATEVでのCSVインポートは静かに失敗します。Buchhalterは、Steuerberaterがバッチを返送するまで問題に気づきません。その時点で、抽出によって節約された時間は形式トラブルシューティングに失われます。
DATEV用に適切に設定された抽出CSVは、汎用的なExcelエクスポートではありません。それはDATEVの方言を話すファイルです:ANSIエンコーディング、セミコロン、DD.MM.YYYY、カンマ小数点、そしてSteuerberaterが期待するSteuerschlüsselに一致する列ヘッダー。形式仕様こそがインターフェースです — APIキーではありません。
E-Rechnung義務化がこの比較に与える影響
ドイツのB2B電子請求書義務化は段階的に施行されています:2025年1月から受領対応が必須となり、2027年までに売上高80万ユーロ超の企業、2028年までに全企業に対して発行が義務付けられます。形式はXRechnung(純粋なXML)とZUGFeRD 2.0.1+(XMLを埋め込んだハイブリッドPDF/A-3)です。理論上、これにより抽出問題は根本から解消されます。すべての請求書が機械可読なXMLで届くなら、OCRやAI抽出は誰も必要としません。
しかし、2025年から2028年への移行期間中の実際の運用はより複雑です。2026年の典型的な財務チームは、大規模サプライヤーからのXRechnung XML(機械可読ですが人間の目には見えず、視覚的レンダリングがありません)、中規模サプライヤーからのZUGFeRDハイブリッドPDF(通常の請求書のように見えますが、多くのメールシステムが削除する構造化データが埋め込まれています)、まだ切り替えが義務付けられていない小規模サプライヤーからの従来のPDF、そして物理的な郵便を送り続ける個人事業主からの撮影された紙の請求書を受け取ります。4つの形式、1つの宛先:月の10日までにSteuerberaterが期待するDATEV CSVです。
ここで2つの哲学が明確に分かれます。ネイティブなXRechnung/ZUGFeRD解析を備えた会計ソフトウェア(DATEV DUO、sevDesk、Lexware Office)は、構造化されたXML形式をうまく処理します。しかし、移行期間中も残る従来のPDFや撮影された請求書については、ソフトウェアは手動データ入力にフォールバックします。XMLパーサーはXRechnungフィールドを完璧に読み取ります。人間はそれ以外のすべてを手動で読み取ります。ワークフローの自動化は、最も構造化されていない入力に依存します。
セマンティック抽出レイヤーはこれを平準化します:構造化された電子請求書用にXRechnung XMLを解析し、同じAIエンジンを使用してPDF、スキャン、写真からフィールドを抽出します。出力は、請求書の到着方法に関係なく、単一の統一されたCSVです。2028年以降、すべてのサプライヤーが構造化された電子請求書を送信する必要がある場合、PDF/スキャン抽出機能はコンプライアンスの安全網となります—主要な取り込み経路ではなく、XMLが破損したZUGFeRDファイルを送信するサプライヤー、義務の範囲外の海外サプライヤー、監査で表面化する2024年の紙の請求書のためのフォールバックです。
よくある質問
AI抽出は手書きのドイツ語請求書に対応していますか?
はい、ただし重要な条件があります。標準的なRechnungレイアウト(Handwerkerが印刷されたテンプレートにペンで記入する種類)の読みやすい手書き文字は、ビジョン言語モデルによって確実に抽出されます。読みにくい手書き文字(Buchhalterが目を細めて同僚に確認を求めるようなもの)は、AIでも解決できません。読みやすい手書きのドイツ語請求書フィールドの精度は通常90%以上ですが、信頼度しきい値を下回る10%は自動承認ではなく、人間によるレビュー用にフラグを立てるべきです。実用的な価値は、AIが手書き請求書の90%を人が触れることなく処理し、境界線上の10%を検証に回すことです。これは、100%すべてを手動で入力するワークフローとは異なります。
AI抽出は§13bリバースチャージ請求書を正しく処理できますか?
はい、ただし明示的な定義が必要です。§13bリバースチャージのシナリオ(EU域内の越境サプライヤー請求書で一般的)は、サプライヤーがVATを請求せず、受領者が自己申告することを意味します。AIはリバースチャージの兆候を検出するように設定できます:VAT行の欠落、「reverse charge」、「Steuerschuldnerschaft des Leistungsempfängers」、「VAT shifted to recipient」などのフレーズの存在。推論列を使用して、リバースチャージ転記に正しいSteuerschlüsselを割り当てることができます。重要なのは「設定」という言葉です。これはすべての抽出ツールで自動的に機能するわけではありません。ロジックを一度定義する必要があり、その後はバッチ内のすべての請求書に一貫して適用されます。
AI抽出を使用しても会計ソフトウェアは必要ですか?
はい、絶対に必要です。AI抽出はデータ入力ステップ(サプライヤーのPDFを受け取ってからスプレッドシートに構造化データが入るまでのワークフロー部分)を置き換えます。転記、VAT申告、銀行照合、財務報告、Steuerberaterとの連携は置き換えません。これらの機能には引き続きDATEV、Lexware、またはsevDeskが必要です。変わるのはデータが会計システムに入る方法です:Buchhalterが入力する代わりに、AIが文書を読み取り、直接インポートできるCSVを出力します。そのインポート後の会計ソフトウェアの役割は変わりません。
AI抽出CSVは単体でGoBD準拠ですか?
いいえ。抽出ツールのCSVは作業用ファイルであり、監査に耐えうるアーカイブではありません。GoBDでは、受領した請求書について、原本(PDF、スキャン、写真)、抽出または入力されたデータ、誰がいつ何を変更したかを記録する改訂安全な監査証跡の3つが求められます。抽出ツールは処理判断の監査ログを生成する必要があります。しかし、GoBD準拠のアーカイブは文書管理システムや会計ソフトウェアに存在するものであり、抽出ツール内にあるものではありません。抽出レイヤーは構造化データと監査ログを生成し、それらが原本の文書画像とともに既存のGoBDアーカイブに取り込まれると考えてください。
クラウドベースのAI抽出におけるDSGVO準拠はどうなっていますか?
これは完全にプロバイダー次第です。ドイツの仕入先請求書には、DSGVOの対象となる個人データ(仕入先名、住所、場合によっては個人のSteuernummer)が含まれています。抽出プロバイダーのホスティング場所とデータ処理契約が重要です。EU内でホスティングされ、文書化されたGDPR準拠、データ処理契約(Auftragsverarbeitungsvertrag、略してAVV)、および自動ファイル削除ポリシーを持つプロバイダーは、法的要件を満たしています。EU外でホスティングされているプロバイダーは、データ転送メカニズムの慎重な審査が必要です。これはAI抽出というカテゴリーの限界ではなく、ベンダー選定の基準です。同じDSGVOの審査は、sevDeskやクラウドホスト型DATEVモジュールを含む、あらゆるクラウドベースの会計ツールに適用されます。
DUOのOCRと専用AI抽出ツールでは、フィールドレベルの精度はどのように比較されますか?
DATEV DUOのOCRは、標準的なドイツの請求書レイアウト(フィールドが従来の方法で一貫して配置されラベル付けされている種類)では高い精度を達成します。しかし、非標準フォーマット、スキャン文書、写真、多言語の請求書では精度が低下します。ビジョン言語モデルを使用する専用のAI抽出ツールは、さまざまなフォーマットの印刷テキストで95〜99%のフィールドレベル精度を達成し、読みやすい手書き文字ではおよそ90%以上の精度を達成します。運用上の違いは精度の数値だけではありません。抽出後の処理が異なります。DUO OCRはDATEVエコシステム内で動作するため、修正は同じインターフェース内で行われます。外部の抽出ツールはフィールドごとに信頼度スコアを提供し、レビュー担当者は信頼度のしきい値を下回るフィールドのみに焦点を当て、すべてを再確認する必要はありません。どちらのワークフローも人間によるレビューが必要です。違いは、請求書のどの程度がレビューされ、どの程度が自動承認されるかです。
迷わず選ぶためのポイント
月に30件以下のドイツの仕入先請求書を処理し、レイアウトを把握している仕入先からの請求書で、SteuerberaterがDATEV内で全てを処理している場合 — 会計ソフトの標準的なデータ入力機能を使い続けてください。抽出レイヤーを追加するのは、必要のない手間です。
月に50件以上の請求書を処理する場合 — 特に、写真、スキャン、PDFで届き、複数言語で、レイアウトが変わる仕入先からの請求書が多い場合 — 状況は意味的抽出に明確に傾きます。ドイツのBuchhalterの人件費を考慮すると、請求書1件あたりの時間削減だけで、一貫して使用した最初の月に抽出ツールのコストを回収できます。
この判断は、会計ソフトを置き換えることではありません。会計ソフトが、Buchhalterの時間の大半を占める作業 — 仕入先のドキュメントを読み取り、その内容をフォームに入力すること — を行うように設計されたことは一度もない、という事実を認識することです。その作業は、あらゆる会計プラットフォームの上流にあります。仕入先の請求書とSteuerberaterのDATEVの間 — そこにワークフロー哲学の判断があります。
無料でお試しいただけます — 最初の50ページはアカウント不要です。実際の月間ボリュームをテストするためのバッチアップロードに対応しています。