Warum die AIA-G702-Dateneingabe
Bauzahlungszyklen verlangsamt

Die Formulare sind Standard. Die Dateneingabe nicht.

Das AIA G702 und das dazugehörige G703 Fortsetzungsblatt werden bei 78 % der gewerblichen Bauprojekte in den USA verwendet. Entwickelt vom American Institute of Architects, bieten diese Formulare eine strenge Struktur für die Abschlagsrechnung: Das G702 fasst den Vertragswert, genehmigte Nachträge, frühere Zahlungen, einbehaltene Sicherheiten und den aktuell fälligen Betrag zusammen, während das G703 jeden Dollar in Einzelposten aufschlüsselt, die nach einem Leistungsverzeichnis organisiert sind. Ihr Zweck ist es, einen einzigen, überprüfbaren Nachweis darüber zu schaffen, welche Arbeiten ausgeführt wurden und welche Zahlung geschuldet wird. In diesem Sinne sind sie erfolgreich – die Formulare selbst sind eindeutig.

Was die Formulare nicht standardisieren, ist das, was mit den Daten passiert, nachdem sie auf der Seite gelandet sind. Der typische Zahlungsantrags-Workflow bei einem AIA-abgerechneten Projekt folgt einem ausgetretenen Pfad: Ein Subunternehmer füllt das G703 aus und trägt den Wert der in diesem Zeitraum abgeschlossenen Arbeiten, gelagerte Materialien, den Fertigstellungsgrad und die kumulierten Summen für jeden der 20 bis 50 Einzelposten ein. Die G702-Zusammenfassung wird dann aus diesen G703-Summen befüllt. Der Subunternehmer reicht das Paket – in der Regel als PDF – beim Generalunternehmer ein. Der Projektmanager oder Buchhalter des GU gibt diese Zahlen dann erneut in das firmeneigene Zahlungsverfolgungssystem ein, sei es Procore, Sage 300 CRE, Viewpoint Vista oder eine gemeinsame Excel-Arbeitsmappe. Wenn der Bauherr oder Architekt eine unabhängige Prüfung vor der Zertifizierung verlangt – wie es die meisten Verträge unter den AIA A201 Allgemeinen Geschäftsbedingungen vorsehen – werden die Daten ein drittes Mal in das System des Bauherrn übertragen. In einigen Fällen verlangt der Kreditgeber des Bauherrn eine vierte Eingabe in eine separate Plattform für Auszahlungsanträge.

Eine einzelne G703 mit 30 Positionen und 10 Spalten Finanzdaten enthält rund 300 diskrete Zahlenwerte. Bei 12 bis 15 Anträgen pro Monat über fünf aktive Projekte hinweg bearbeitet das Projektmanagement-Team eines Generalunternehmers etwa 4.500 Zahlen pro Abrechnungszyklus – jede einzelne muss auf Richtigkeit geprüft werden, und die meisten müssen manuell in ein anderes System eingegeben werden als das, in dem sie ankamen. Das Formular standardisiert, was die Zahlen bedeuten, nicht, wie sie sich bewegen.

Wenn ein kleiner Dateneingabefehler eine Zahlungsverzögerung von 30 Tagen auslöst

Ein abgelehnter Zahlungsantrag wird nicht einfach korrigiert und am nächsten Tag wieder eingereicht. In den meisten Bauverträgen ist das Abrechnungsfenster festgelegt – Anträge müssen bis zu einem bestimmten Datum jedes Monats eingereicht werden, oft am 20. oder 25. Lehnt ein Architekt oder Bauherr einen Zahlungsantrag aus irgendeinem Grund ab – ein Rechenfehler, eine G702-Summe, die nicht mit der G703 übereinstimmt, ein falsch angewandter Einbehaltssatz – muss der Auftragnehmer den Fehler beheben und den Antrag erneut einreichen. Aber bis die Überarbeitung vorbereitet, geprüft und durch die Genehmigungskette zurückgeschickt ist, ist das Abrechnungsfenster in der Regel geschlossen. Die Zahlung verschiebt sich in den folgenden Monatszyklus. Ein einziger Dateneingabefehler – eine falsche Ziffer in einer 300-Werte-Tabelle – kann eine 30-tägige Liquiditätslücke verursachen.

Manche Fehler sind besonders tückisch, weil sie sich über mehrere Abrechnungszeiträume hinweg aufschaukeln. Das G703 ist als kumulatives Formular aufgebaut: Zeile 6 („Gesamtsumme der bis heute fertiggestellten und eingelagerten Leistungen“) im G702 muss mit der Gesamtsumme im G703 übereinstimmen, und die kumulierte Summe jeder Position im aktuellen Zeitraum muss der kumulierten Summe des vorherigen Zeitraums plus den im aktuellen Zeitraum fertiggestellten Leistungen entsprechen. Kopiert ein Subunternehmer das G703 des Vormonats, um die Abrechnung des laufenden Monats zu beginnen, und aktualisiert die Spalte „im aktuellen Zeitraum“, vergisst aber, die tatsächlich genehmigten Zahlen des Vormonats zu übernehmen, ist jede einzelne Position falsch. Der Architekt lehnt den gesamten Antrag ab – nicht nur die Position mit dem Fehler. Die Uhr läuft neu. Und weil der Fehler in der Übertragung liegt, sind die internen Aufzeichnungen des Subunternehmers nicht mehr mit denen des Generalunternehmers abgestimmt, was ein Abstimmungsproblem schafft, das bis in den nächsten Abrechnungszyklus hineinreicht.

Dabei handelt es sich nicht um einen seltenen Ausnahmefall. Ein Subunternehmer auf r/Construction beschrieb die monatliche Rechnerei, um unter genau diesen Bedingungen liquide zu bleiben: den ersten Zahlungsantrag am 15. Januar einreichen, die erste Zahlung um den 15. März herum erwarten – eine Vorlaufzeit von 60 Tagen. In dieser Lücke werden Materialien zu Zahlungszielen von 30 Tagen bestellt, was bedeutet, dass der Subunternehmer 25 Tage lang Einkäufe aus eigener Tasche finanziert, ohne dass dafür Zahlungen eingehen. „Ich habe Schwierigkeiten, beim Cashflow die Nase vorn zu behalten“, schrieb er, „und wir kommen der Gefahr, die Bank zu sprengen, unangenehm nahe.“

Die 56-Tage-Lücke, die auf GC-Seite niemand sieht

Laut Billds National Subcontractor Market Report 2025 warten Subunternehmer nach Einreichung eines Zahlungsantrags durchschnittlich 56 Tage auf die Zahlung. Generalunternehmer schätzen die Wartezeit auf 30 Tage. Diese 26-tägige Wahrnehmungslücke ist nicht trivial – sie bedeutet, dass diejenigen, die den Zahlungszeitplan kontrollieren, nicht wirklich verstehen, wie lange diejenigen, die auf die Zahlung warten, tatsächlich warten. Von oben erscheint die Pipeline kürzer als von unten.

Die Lücke wird noch größer, wenn man über einen einzelnen Zahlungszyklus hinausblickt. Der Siteline-Bericht „State of Subcontractor Billing 2025“ ergab, dass nur 5 % der Subunternehmer konsequent pünktlich bezahlt werden. Die restlichen 95 % warten durchschnittlich 96 Tage – mehr als drei Monate – von der Fertigstellung der Arbeiten bis zum Zahlungseingang. Die Construction Financial Management Association (CFMA) erfasst die Days Sales Outstanding (DSO) als zentrale Finanzkennzahl für Bauunternehmen. Die Branchenbenchmarks von CreditPulse 2025 setzen den durchschnittlichen DSO im Baugewerbe auf 83 Tage an, verglichen mit rund 60 Tagen in allen US-Branchen. Ausbaugewerke liegen bei durchschnittlich 77 Tagen. Ingenieur- und Bauunternehmen erreichen 100 Tage. Zum Vergleich: Der von Baufinanzanalysten genannte gesunde DSO-Zielwert liegt bei 45 Tagen – etwa der Hälfte des Branchendurchschnitts.

Was diese Zahlen mit dem Problem der Dateneingabe verbindet, ist die Kettenreaktion, die in jedem Abrechnungszyklus steckt. Jede manuelle Neueingabe einer Zahl – von der Tabelle des Subunternehmers in die Procore-Instanz des Generalunternehmers, vom System des GU in den Zahlungsantrag des Bauherrn, von der Prüfung des Bauherrn zur Verifizierung durch den Kreditgeber – schafft eine neue Möglichkeit für Abweichungen. Jede Abweichung erfordert eine Klärungs-E-Mail. Jede Klärungs-E-Mail verlängert den Prüfungszeitraum um ein bis zwei Tage. Am Ende der Kette hat der Subunternehmer, der den ursprünglichen G703 vor 56 Tagen eingereicht hat, keine Einsicht, welche dieser Neueingaben die Verzögerung verursacht hat – nur, dass die Zahlung noch nicht eingegangen ist.

Der PYMNTS- und American-Express-Bericht 2025 zu verspäteten Zahlungen im Baugewerbe ergab, dass 69 % der Bauunternehmen Zahlungen noch per Papierscheck abwickeln. Manuelle Zahlungssysteme, so der Bericht, „verstärken die Liquiditätsprobleme in Bauprojekten“. In derselben Umfrage nannten Generalunternehmer kreditgeberbedingte Verzögerungen (38 %) und Probleme im Prozessmanagement (27 %) als die beiden größten Hindernisse für pünktliche Zahlungen – beide Kategorien umfassen den Zeitaufwand für den Abgleich von Daten aus mehreren Systemeingaben.

Wer zahlt eigentlich für all diese Verzögerungen

Es liegt nahe, langsame Zahlungszyklen als branchenweite Ineffizienz darzustellen – eine abstrakte Zahl von 280 Milliarden Dollar, die den gesamten Sektor betrifft. Doch Ineffizienz bei Bauzahlungen verteilt sich nicht gleichmäßig. Sie konzentriert sich am unteren Ende der Zahlungskette. Subunternehmer kaufen Materialien, bezahlen Arbeitskräfte und tragen Versicherungskosten, bevor sie einen einzigen Dollar vom Generalunternehmer erhalten. Sie gewähren damit faktisch jedem Projekt, an dem sie arbeiten, Kredit – einen Kredit, den sie nicht freiwillig gewähren und den sie nicht in ihre Angebote einpreisen können, ohne wettbewerbsunfähig zu werden.

Billds Umfrage von 2025 beziffert, wie das in der Praxis aussieht: 75 % der Subunternehmer bezahlen Materialien aus eigenen Rücklagen, während sie auf Zahlung warten. Jeder dritte Subunternehmer hat auf private Ersparnisse oder die Altersvorsorge zurückgegriffen, um Liquiditätslücken durch verspätete Zahlungen zu schließen. Der Anteil der Subunternehmer, die Materialkosten aus eigener Tasche bezahlen, stieg von 66 % im Jahr 2021 auf 73 % im Jahr 2023 und liegt seitdem konstant über 75 % – ein Trend in die falsche Richtung, obwohl sich die Gesamtwirtschaft stabilisiert hat. Und 86 % der Subunternehmer finanzieren Lohnkosten – wöchentliche Gehälter für ihre Teams – während sie auf Forderungen warten, die erst nach 56 bis 96 Tagen fällig werden. Subunternehmer fungieren im Grunde als Working-Capital-Geber der Bauindustrie – nur ohne Zinsen.

In den Bundesstaaten der USA gibt es gesetzliche Regelungen für die pünktliche Zahlung, um dieses Ungleichgewicht zu beheben. Kaliforniens Prompt Payment Act verlangt von privaten Bauherren, dass sie Generalunternehmer innerhalb von 30 Tagen nach einer ordnungsgemäßen Rechnung bezahlen, mit einer monatlichen Verzugszinsstrafe von 2 %. Ab Januar 2026 hat Kalifornien zudem den Einbehalt (Retainage) bei privaten Projekten auf 5 % gedeckelt – eine Anerkennung, dass das Zurückhalten von 10 % jeder Abschlagszahlung über Jahre hinweg eine enorme Belastung des Betriebskapitals von Subunternehmern darstellt. Texas verlangt gemäß Kapitel 28 seines Property Code, dass Bauherren innerhalb von 35 Tagen zahlen, und schreibt vor, dass Auftragnehmer die Zahlung innerhalb von 7 Tagen nach Erhalt an Subunternehmer weiterleiten müssen. Beide Bundesstaaten erlauben es Auftragnehmern, die Arbeit einzustellen, wenn unbestrittene Beträge nicht gezahlt werden. Diese Gesetze regeln jedoch die Zahlung nachdem ein korrekter Antrag eingereicht und genehmigt wurde. Sie befassen sich nicht mit den Wochen der Verzögerung, die vorder Qualifikation des Antrags als korrekt auftreten – dem Engpass bei der Dateneingabe und -prüfung, den die meisten Auftragnehmer als den "Abrechnungszyklus" selbst erleben.

Die gesetzlichen Schutzmaßnahmen greifen erst am Ziel, nicht am Start. Und der Start – an dem ein Subunternehmer mit der G703 des Vormonats, einer neuen Tabelle und 300 zu übertragenden Werten Platz nimmt – ist für das Gesetz völlig unsichtbar.

Die Extraktionsebene, die die Formulare selbst übersehen haben

Als die AIA Anfang der 1990er Jahre die G702 und G703 entwarf – die Ausgabe von 1992 ist noch immer die am weitesten verbreitete Version – bestand das Problem, das die Formulare lösen mussten, in der Einheitlichkeit. Ein Standardformat bedeutete, dass alle Beteiligten eines Projekts dieselbe Abrechnungssprache sprachen, was Streitigkeiten darüber reduzierte, was eine ordnungsgemäße Zahlungsanforderung ausmacht. Die dem Design zugrunde liegende Annahme war, dass die Formulare selbst, einmal standardisiert, die einzige maßgebliche Aufzeichnung sein würden – einmal ausgefüllt, einmal geprüft, einmal zertifiziert.

Was die Designer nicht vorhersehen konnten, war die Vielzahl an Softwaresystemen, die jeweils eine eigene Kopie derselben Daten benötigen würden. Das G702/G703-Formular wurde zur Präsentationsschicht – dem PDF, das zwischen den Parteien zirkuliert – aber jede Partei brauchte die Daten aus diesem PDF dennoch in ihrem eigenen System: der Subunternehmer in QuickBooks oder Jonas Premier, der Generalunternehmer in Procore oder Viewpoint Vista, der Eigentümer in Acumatica Construction Edition, die Bank in ihrer Auszahlungsplattform. Das Standardformular standardisierte die Oberfläche, nicht die darunterliegende Ebene. Und die Brücke zwischen beiden zu schlagen – das Formular zu lesen und seine Daten in ein anderes System zu übertragen – blieb eine rein manuelle Tätigkeit.

Hier wird KI-gestützte Dokumentenextraktion, statt einer weiteren Projektmanagement-Plattform, zum fehlenden Puzzlestück. Anstatt jede Partei in der Zahlungskette zur Nutzung derselben Software zu bewegen – ein Koordinationsproblem, das seit drei Jahrzehnten ungelöst ist – fügen Extraktionstools eine schlanke Datenschicht zwischen Formular und System ein. Sie geben die gewünschten Spaltennamen vor – „Position Beschreibung", „Vertragswert", „Diese Periode geleistete Arbeit", „Gesamt geleistet und eingelagert bis heute", „Einbehalt" – und das Tool liest das PDF, lokalisiert jeden Wert, indem es die Bedeutung der Spaltenüberschriften versteht, nicht deren Position auf der Seite, und gibt eine strukturierte Tabelle aus. Dieser Ansatz, genannt Spaltennamenextraktion, funktioniert anders als template-basierte OCR: Statt Kästchen um jedes Feld auf jedem Formular zu zeichnen, geben Sie die benötigten Feldnamen ein, und die KI findet die entsprechenden Werte überall im Dokument basierend auf semantischem Verständnis des Formularlayouts. Die Ausgabe ist eine Tabelle – Excel oder CSV – die direkt in jedes von den Parteien bereits genutzte System übernommen werden kann.

Das Formular ändert sich nicht. Der Einreichungsablauf ändert sich nicht. Der Subunternehmer füllt weiterhin die G703 aus und reicht das PDF ein. Der Generalunternehmer prüft es weiterhin. Was sich ändert, ist, dass niemand mehr 300 Zahlen von einem Bildschirm in einen anderen abtippen muss. Die Extraktionsebene liest das PDF und liefert die Daten als strukturierte Spalten – das eliminiert die manuelle Neueingabe, die sowohl Fehler als auch Verzögerungen verursacht. Eine detaillierte Erklärung, wie dies speziell mit G702- und G703-Formularen funktioniert – inklusive Vertragssummen, Einbehaltsberechnungen und Einzelposten-Extraktion – finden Sie in unserem Schritt-für-Schritt-Leitfaden zur Extraktion von AIA-G702-Zahlungsantragsdaten in Tabellenkalkulationen. Falls Sie die Dateneingabe von Dokumenten allgemein automatisieren möchten, finden Sie auf unserer Seite automatisierte Dateneingabe, wie die Spaltennamenextraktion über verschiedene Dokumententypen hinweg funktioniert.

FAQ

Warum verursacht ein abgelehnter G702/G703-Zahlungsantrag eine so lange Verzögerung?

Die meisten Bauverträge legen ein festes monatliches Abrechnungsfenster fest – Anträge, die nach Ablauf der Frist eingereicht oder nach Ablehnung erneut eingereicht werden, warten in der Regel auf den nächsten monatlichen Zyklus. Eine Ablehnung aufgrund eines Rechenfehlers oder einer Diskrepanz zwischen den Summen von G702 und G703 erfordert nicht nur eine Korrektur; sie setzt effektiv die 30- bis 45-tägige Genehmigungsuhr zurück. Bis der korrigierte Antrag erneut eingereicht, geprüft, zertifiziert und bezahlt ist, kann die ursprüngliche Arbeit bereits 90 Tage oder länger zurückliegen.

Verursachen Generalunternehmer diese Verzögerungen absichtlich?

Die meisten Verzögerungen sind nicht beabsichtigt – sie sind verfahrensbedingt. Projektmanager und Buchhalter von GU bearbeiten monatlich Zahlungsanträge von mehreren Subunternehmern für mehrere Projekte. Jeder Antrag erfordert eine Prüfung: ob die G703-Posten mit der G702-Gesamtsumme übereinstimmen, ob die Übertragswerte mit der Vorperiode übereinstimmen, ob die Einbehalte gemäß Vertrag korrekt berechnet wurden und ob die Begleitdokumente (Verzichtserklärungen, Nachtragsaufträge, Versicherungsbescheinigungen) vollständig sind. Die Prüfung selbst ist notwendig. Verlangsamt wird sie dadurch, dass die zu prüfenden Daten in einer PDF-Datei vorliegen, die Prüfwerkzeuge jedoch in einer Tabelle – und diese Lücke zu schließen erfordert manuelle Eingaben.

Wie unterscheidet sich die Dokumentenextraktion von Bauprojektmanagement-Software wie Procore?

Procore, Viewpoint Vista, Sage 300 CRE und ähnliche Plattformen sind vollständige Projektmanagement-Ökosysteme – sie decken Kostenschätzung, Terminplanung, Dokumentenkontrolle, Baukommunikation und Abrechnung in einem System ab. Die Dokumentenextraktion ist ein schlankeres, leichteres Werkzeug: Sie liest eine PDF-Datei (z. B. ein G702/G703-Paket), extrahiert die strukturierten Daten und gibt sie als Tabelle aus. Sie ersetzt keine PM-Plattform; sie sitzt zwischen der PDF-Datei und Ihrem bestehenden System und eliminiert den Schritt der manuellen Dateneingabe. Dies ist besonders nützlich, wenn verschiedene Beteiligte am selben Projekt unterschiedliche PM-Plattformen verwenden – das Extraktionswerkzeug arbeitet mit der PDF-Datei selbst, unabhängig davon, welches System die Daten letztendlich erhält.

Helfen Prompt-Payment-Gesetze Subunternehmern tatsächlich, schneller bezahlt zu werden?

Staatliche Gesetze zu pünktlichen Zahlungen legen gesetzliche Fristen und Verzugszinsen fest. Das kalifornische Prompt Payment Act verlangt beispielsweise, dass private Bauherren innerhalb von 30 Tagen zahlen, und erhebt 2 % monatliche Verzugszinsen. Texas schreibt eine Zahlungsfrist von 35 Tagen für den Bauherrn und eine Weitergabe innerhalb von 7 Tagen an die Nachunternehmer vor. Diese Gesetze bieten wichtige Rechtsmittel, nachdem ein ordnungsgemäß eingereichter Antrag zertifiziert wurde. Sie befassen sich jedoch nicht mit der Verzögerung vor der Zertifizierung – den Wochen, die mit der Korrektur von Dateneingabefehlern, dem Abgleich von Übertragungsdifferenzen und dem Warten auf mehrere Prüfinstanzen vergehen. Diese Verzögerung liegt außerhalb des Anwendungsbereichs der Prompt-Payment-Gesetze, in der Lücke zwischen Antragseinreichung und Antragszertifizierung.

Was ist der Unterschied zwischen „Pay-if-Paid“- und „Pay-when-Paid“-Klauseln in Bauverträgen?

Eine Pay-when-Paid-Klausel regelt den Zeitpunkt: Der Generalunternehmer muss den Nachunternehmer innerhalb einer angemessenen Frist nach Zahlungseingang vom Bauherrn bezahlen – sie bestimmt, wann gezahlt wird. Eine Pay-if-Paid-Klausel geht weiter: Sie macht den Zahlungseingang des Generalunternehmers vom Bauherrn zu einer aufschiebenden Bedingung für die Zahlungspflicht gegenüber dem Nachunternehmer – sie verlagert das Risiko der Nichtzahlung durch den Bauherrn vollständig auf den Nachunternehmer. Die Bundesstaaten behandeln Pay-if-Paid-Klauseln unterschiedlich: Gerichte in Kalifornien haben sie für unwirksam erklärt, da sie faktisch auf das Recht der Bauhandwerkersicherung verzichten, während Texas sie zulässt, sofern sie eindeutig und unmissverständlich sind. In der Praxis verlängern beide Klauseltypen die Wartezeit des Nachunternehmers auf Zahlung – und beide erhöhen die Kosten jedes Dateneingabefehlers, der Tage oder Wochen zum Genehmigungsprozess der vorgelagerten Stelle hinzufügt.

Ist das nur ein Problem für große gewerbliche Auftragnehmer oder betrifft es auch kleinere Nachunternehmer?

Kleinere Subunternehmer sind überproportional betroffen. Große Generalunternehmer und Spezialfirmen mit eigener Buchhaltung können Zahlungszyklen von 56 bis 96 Tagen durch Kreditlinien, Rücklagen oder Lieferantenbeziehungen mit verlängerten Zahlungszielen abfedern. Ein kleiner Subunternehmer mit drei Kolonnen, wöchentlicher Lohnabrechnung und ohne Kreditlinie hat keinen solchen Puffer. Daten aus Billds National Subcontractor Market Report 2025 zeigen, dass 75 % der Subunternehmer Materialien aus eigener Tasche vorfinanzieren, während sie auf Zahlung warten – und je kleiner das Unternehmen, desto wahrscheinlicher greift es auf private Ersparnisse oder Rentenfonds zurück, um die Lücke zu überbrücken. Für einen Subunternehmer mit 400.000 US-Dollar Auftragsvolumen verteilt auf mehrere Projekte kann eine einzige 30-tägige Zahlungsverzögerung durch eine abgelehnte Zahlungsanforderung bedeuten, dass die Lohnzahlung ausfällt.

Können handelsübliche KI-Extraktionstools sowohl die G702-Zusammenfassung als auch die G703-Positionen verarbeiten?

Die G702 und G703 stellen unterschiedliche Extraktionsanforderungen. Die G702 ist eine einseitige Zusammenfassung mit etwa 10 Einzelfeldern – Vertragssumme, Nachtragsaufträge, Einbehalt, bisherige Zahlungen, aktueller Rechnungsbetrag. Diese sind relativ einfach zu extrahieren. Die G703 ist ein mehrseitiges Fortsetzungsblatt mit potenziell Hunderten von Einzelposten, die jeweils Werte in mehreren Spalten enthalten, deren Zeilenintegrität gewahrt bleiben muss – der Wert in Spalte D, Zeile 12 muss korrekt der Beschreibung des Einzelpostens in Spalte B, Zeile 12 zugeordnet sein. Allgemeine KI-Extraktionstools können die G702-Felder verarbeiten, verlieren jedoch bei der G703 die Zeilenausrichtung. Tools für die strukturierte Dokumentenextraktion, wie die Spaltennamenextraktion von ImageToTable.ai, bewahren die Zeilenintegrität, indem sie jede Spalte als benanntes Feld über alle Zeilen behandeln – so wird „In diesem Zeitraum ausgeführte Arbeiten“ als einzelne Spalte mit einem Wert pro Einzelposten extrahiert. Eine vollständige Anleitung finden Sie in unserem Leitfaden zum automatischen Extrahieren von AIA G702/G703 Zahlungsanforderungsdaten.