Häufige G702-Extraktionsfehler
Die Zahlungs-App-Streitigkeiten auslösen

Die meisten Anleitungen zu G702/G703-Formularen konzentrieren sich auf das Offensichtliche: Rechnung prüfen, Fristen einhalten, Sicherheitseinbehalte nicht vergessen. Das ist wichtig. Aber wenn Sie von der manuellen Formularerfassung zur Datenextraktion aus PDFs und Tabellen in eine einzige Zahlungsanforderung übergehen – oder wenn Sie als Generalunternehmer die Einreichungen von zwanzig Subunternehmern in einem einzigen Abrufplan konsolidieren – treten andere Fehlerarten in den Vordergrund. Es sind Fehler, die selbst eine saubere Taschenrechner-Prüfung überstehen, weil sie nicht auf falschen Summen beruhen. Sie beruhen darauf, dass von vornherein die falsche Zahl in die Summe einfließt.

Wenn die Zahlen stimmen, Ihre Zahlungsanforderung aber trotzdem zurückkommt

Es gibt eine besondere Frustration, die jeder kennt, der über mehrere Abrechnungszyklen hinweg Baurechnungen verwaltet hat: Sie prüfen jede Summe, die Nachrechnung des Sicherheitseinbehalts stimmt, die G703-Gesamtsumme entspricht Zeile 4 der G702 – und der Architekt oder Bauherr schickt sie trotzdem mit einem Fragezeichen neben einer Zahl zurück. Das Problem ist nicht, dass die Rechnung falsch ist. Das Problem ist, dass irgendwo zwischen den Quelldokumenten und dem endgültigen Formular eine Zahl ihre Bedeutung geändert hat, ohne ihren Wert zu ändern.

Dies ist der entscheidende Unterschied zwischen oberflächlichen Formularfehlern und Extraktionsfehlern. Ein oberflächlicher Fehler – eine vertauschte Ziffer, eine vergessene Subtraktion – fällt sofort auf. Ein Extraktionsfehler wirkt isoliert betrachtet korrekt. Er wird erst sichtbar, wenn jemand ihn zu seiner Quelle zurückverfolgt und feststellt, dass die Quelle nicht mit dem übereinstimmt, was im Formular gelandet ist. Die sechs häufigsten Ursachen dafür zu kennen, ist der Unterschied zwischen einer Zahlungsanforderung, die die erste Prüfung besteht, und einer, die einen Streit auslöst, der Sie einen gesamten Abrechnungszyklus kostet.

1. Die Falle bei der Extraktion von kumulierten vs. aktuellen Periodenwerten

Auf dem G703 Fortsetzungsblatt haben die Spalten D und E grundlegend unterschiedliche Funktionen. Spalte D überträgt die kumulierten genehmigten Summen aller vorherigen Anträge. Spalte E erfasst nur die in diesem Abrechnungszeitraum ausgeführten Arbeiten. Spalte G — Gesamtsumme der bis dato ausgeführten und eingelagerten Arbeiten — ist die Summe aus D, E und den in diesem Zeitraum in F eingelagerten Materialien. Die für die G702-Zusammenfassung relevante Zahl ist Spalte G.

Dennoch ist der häufigste Fehler bei der Datenextraktion aus einem Stapel von Dokumenten — ob Sie von einer markierten G703 abschreiben, aus der Tabelle eines Subunternehmers übernehmen oder ein KI-Extraktionstool zum Lesen gescannter Zahlungsanträge verwenden — die Verwechslung von Spalte E (nur dieser Zeitraum) mit Spalte G (Gesamtsumme bis dato). Der Subunternehmer meldet, dass er diesen Monat Elektroarbeiten im Wert von 45.000 $ abgeschlossen hat. Diese 45.000 $ kommen in Spalte E. Aber Spalte G für diese Position sollte die kumulierte Summe anzeigen — alle seit Projektbeginn abgeschlossenen Arbeiten, die vielleicht 180.000 $ betragen. Wenn Sie diese 45.000 $ als kumulierten Wert extrahieren, unterschätzt Zeile 4 der G702 die tatsächlich ausgeführten Arbeiten um 135.000 $. Der Bauherr sieht eine Zahl, die nicht mit seiner Baustellenbeobachtung des Fortschritts übereinstimmt, und beanstandet den gesamten Antrag.

Der umgekehrte Fehler — die Extraktion des kumulierten Werts in die Spalte des aktuellen Zeitraums — bläht die Abrechnung für diesen Monat auf und löst eine Überzahlungsprüfung aus. Keiner der Fehler zeigt sich bei einer einfachen Quersummenprüfung, da die interne Arithmetik der G702 in sich konsistent bleibt. Der Fehler tritt erst zutage, wenn jemand die eingereichten Zahlen mit dem physischen Baufortschritt vergleicht, wie es AIA A201-2017 Abschnitt 9.4 verlangt, der dem Architekten die Befugnis gibt, nur einen Teil des Antrags zu bescheinigen, wenn die Beträge nicht die tatsächlich ausgeführten Arbeiten widerspiegeln.

Die Lösung beginnt mit dem Verständnis, welche Spalte in Ihrem Extraktionsziel welchem Konzept in Ihrer Quelle entspricht. Wenn Sie ein Extraktionstool verwenden, das Dokumente in eine strukturierte Tabelle verarbeitet – ein Prozess, der manchmal als Spaltennamensextraktion bezeichnet wird, bei dem Sie die gewünschten Felder angeben und die KI die passenden Werte auf jeder Seite findet – stellen Sie sicher, dass Ihre Spaltendefinitionen explizit zwischen „Diese Periode abgeschlossene Arbeiten" und „Bisher insgesamt abgeschlossen" unterscheiden. Wenn das Quelldokument nur periodische Zahlen meldet, benötigen Sie einen separaten Mechanismus, um diese über Abrechnungszyklen hinweg zu akkumulieren, bevor sie in die Nähe des G703 gelangen.

2. Einbehalt auf falscher Basis

Der Einbehalt bei einem G702/G703-Paar wird auf Basis des kumulierten Gesamtwerts der abgeschlossenen Arbeiten und eingelagerten Materialien berechnet, nicht auf Basis des in dieser Periode abgerechneten Betrags. Ein Subunternehmer schließt diesen Monat Arbeiten im Wert von 50.000 $ ab, wodurch sich der kumulierte Gesamtwert auf 200.000 $ erhöht. Bei einem vertraglichen Einbehaltssatz von 10 % beträgt der Einbehalt für diese Position 20.000 $ – zehn Prozent von 200.000 $ –, nicht 5.000 $. Die Anwendung von 10 % auf die periodischen 50.000 $ führt zu einer Unterdeckung des Einbehalts um 15.000 $.

Dieser Fehler unterläuft bei der Datenextraktion schnell, da Einbehaltsätze oft in einem einzigen Vertragsfeld stehen – „Einbehalt: 10 %“ –, während sich der Betrag, auf den dieser Satz angewendet wird, mit jeder Abrechnungsperiode ändert. Wenn Ihr Extraktionsworkflow „10 %“ aus dem Vertrag ausliest und mit dem nächstgelegenen Dollarbetrag auf der Seite multipliziert, können Sie nicht garantieren, welcher Betrag erfasst wurde. Bei G703-Formularen – einer detaillierten Leistungsübersicht, die die Vertragssumme in Arbeitsabschnitte unterteilt – kann der Einbehalt sogar je nach Position variieren. Manche Verträge senken den Einbehalt nach wesentlicher Fertigstellung von 10 % auf 5 %, sodass verschiedene Zeilen im selben G703 unterschiedliche Einbehaltsätze aufweisen.

Das Landesrecht fügt eine weitere Ebene hinzu. New York begrenzt den Einbehalt nun auf 5 % bei privaten Bauverträgen über 150.000 $; vertragliche Regelungen, die diese Grenze überschreiten, sind nichtig und nicht durchsetzbar. Illinois erlaubt 10 % in der ersten Vertragshälfte und schreibt dann eine Reduzierung auf 5 % vor. North Carolina verbietet Einbehalte bei Projekten unter 100.000 $ vollständig. Wenn Ihr Extraktionsworkflow pauschal 10 % auf ein Projekt anwendet, das einem dieser Gesetze unterliegt, führt die Diskrepanz zwischen dem einbehaltenen Betrag und dem rechtlich Zulässigen sofort zu einem Streit – und in manchen Rechtsräumen zu einem Gesetzesverstoß.

Die Construction Financial Management Association (CFMA) hat dokumentiert, dass Fehler und Abstimmungsprobleme allein durch Falschmeldungen und verzögerte Entscheidungen die Projektkosten um 2–5 % erhöhen können. Bei einem 5-Millionen-Dollar-Projekt sind das 100.000–250.000 $ an vollständig vermeidbaren Kosten – größtenteils verursacht durch Gelder, die im Streit liegen, statt durch die Zahlungskette zu fließen.

3. Nachtragsdaten, die zwischen G702 und G703 abweichen

Die G702 enthält eine Nachtragszusammenfassung, die in Zeile 2 (Nettoänderung durch Nachträge) und schließlich in Zeile 3 (Vertragssumme bis heute) einfließt. Genehmigte Nachträge erscheinen auf der G703 als zusätzliche Positionen mit eigenem Planwert und Fortschrittsverfolgung. Diese beiden Darstellungen müssen übereinstimmen: Die Summe aller Nachtragspositionen auf der G703 muss dem Betrag entsprechen, der über die Nachtragszusammenfassung der G702 in Zeile 2 fließt.

Bei der Extraktion von Nachtragsdaten aus mehreren Quellen treten zwei Fehler mit vorhersehbarer Regelmäßigkeit auf. Der erste ist die Einbeziehung nicht genehmigter Nachträge in die Summen. Ein Subunternehmer hat fünf ausstehende Nachträge in Höhe von insgesamt 35.000 $ und führt sie als Positionen in seiner G703 auf – eine Praxis, vor der die G703-Anleitung der AIA warnt: Nachträge sind „entweder auf einem eigenen G703-Formular oder am Ende des Grundplans separat aufzuführen". Wenn der Generalunternehmer oder Architekt die G703 des Subunternehmers prüft und Beträge für Arbeiten findet, die nie genehmigt wurden, ist der gesamte Antrag fragwürdig.

Das zweite Muster ist subtiler: Der Änderungsauftragsbetrag erscheint korrekt in der G703-Position, aber die Zusammenfassung in der G702-Änderungsauftragsübersicht fehlt oder ist null. Die G703 weist 35.000 $ an genehmigten Änderungsaufträgen aus. Die G702, Zeile 2, zeigt 0 $. Die Diskrepanz zwischen detaillierter Aufstellung und Zusammenfassung ist ein direkter Ablehnungsgrund gemäß AIA A201-2017 Abschnitt 9.3, der für Zahlungsanträge fordert, „den Status der Vertragssumme zum aktuellen Zeitpunkt anzugeben, einschließlich des Gesamtbetrags der bis dato ausgeführten und eingelagerten Arbeiten, des Einbehalts (falls vorhanden), der Summe früherer Zahlungen, einer Zusammenfassung der Änderungsaufträge und des Betrags der aktuell beantragten Zahlung.“ Ist die Änderungsauftragsübersicht unvollständig, ist der Antrag unvollständig.

Extraktions-Workflows verschärfen dies, wenn Änderungsaufträge in getrennten Systemen erfasst werden – Procore für das Verpflichtungsmanagement, eine Tabelle für Nachunternehmer-Änderungsprotokolle, ein PDF des unterzeichneten Änderungsauftragsformulars – und jemand alle drei in einen einzigen G702-Eintrag überführen muss. Wird eine Quelle übersehen, beginnt die Kaskade. Für einen tieferen Einblick, wie manuelle Datenschnittstellen zwischen diesen Systemen den gesamten Zahlungszyklus verzögern, lesen Sie unsere Analyse zu warum manuelle G702-Dateneingabe Bauzahlungszyklen verzögert.

4. Bewertung eingelagerter Materialien, die die Positionsobergrenze überschreitet

Spalte F des G703 — Derzeit eingelagerte Materialien — erfasst den Wert der gekauften und auf der Baustelle befindlichen Materialien (oder, gemäß bestimmten Vertragsklauseln, außerhalb der Baustelle in einem Zollager eingelagerten Materialien). Es gibt eine strukturelle Einschränkung, die bei der manuellen Prüfung auffällt, bei der automatischen Extraktion jedoch oft übersehen wird: Die eingelagerten Materialien für eine einzelne Position dürfen den geplanten Wert dieser Position nicht übersteigen. Wenn eine Position einen Gesamtwert von 50.000 $ hat, können Sie nicht 55.000 $ an eingelagerten Materialien dafür geltend machen – das würde bedeuten, dass Sie mehr Materialwert in Rechnung stellen als den gesamten Leistungsumfang.

Dieser Fehler tritt in Extraktionsworkflows auf zwei Wegen auf. Weg eins: Die Materialrechnung des Subunternehmers weist eine gelieferte Menge aus, deren Wert die SOV-Zuteilung übersteigt, und das Extraktionstool übernimmt den Rechnungsbetrag getreu, ohne die SOV-Obergrenze zu prüfen. Weg zwei: Materialien wurden in einer vorherigen Periode unter einer Position eingelagert, aber fortlaufende Materiallieferungen werden derselben Position zugeordnet, anstatt einer separaten, reinen Materialposition. Der kumulierte Wert überschreitet die Obergrenze, und der G703 weist einen negativen Restbetrag aus – eine sofortige rote Flagge, die die Zertifizierung stoppt.

Der G703 ist nicht nur eine Liste von Zahlen. Er ist ein System von Einschränkungen: Jede Position hat einen Höchstwert, kumulierte Summen können nicht sinken, der Einbehalt darf den vertraglichen Satz nicht überschreiten, eingelagerte Materialien dürfen den geplanten Wert nicht übersteigen, und der Restbetrag darf nicht negativ werden. Wenn die Extraktion jede Spalte als unabhängiges Feld behandelt – anstatt als verknüpfte Variable in einem eingeschränkten System –, erzeugt sie zuverlässig Daten, die eine spaltenweise Prüfung bestehen, aber die Querverbundvalidierung nicht bestehen, die ein erfahrener Projektbuchhalter in Sekundenschnelle durchführt.

5. Das Problem der Übertragung vorheriger Zahlungen

Zeile 7 im G702 — abzüglich vorheriger Zahlungsnachweise — ist die häufigste Fehlerquelle im gesamten Zahlungsverkehrssystem. Sie bildet die Summe aller zuvor genehmigten Zahlungen für das Projekt ab. Beim ersten Zahlungsantrag beträgt sie null. Bei jedem weiteren Antrag muss sie exakt mit Zeile 6 (fälliger Zahlungsbetrag) des zuletzt genehmigten G702 übereinstimmen — nicht des zuletzt eingereichten, nicht des zuletzt entworfenen, sondern des zuletzt bestätigten.

So sieht das in der Praxis aus. Antrag #3 wird mit einer Zahlungsforderung von 94.000 $ eingereicht. Der Architekt bestätigt nur 87.000 $ und behält 7.000 $ wegen unvollständiger Unterlagen ein. Das System des Subunternehmers führt den eingereichten Betrag von 94.000 $ als Übertragswert fort. Antrag #4 kommt mit Zeile 7 in Höhe von 94.000 $. Doch die Unterlagen des Bauherrn — und der Vertrag — besagen, dass der korrekte Übertragswert 87.000 $ beträgt. Jeder von Zeile 7 abhängige Wert — der fällige Zahlungsbetrag, der Restbetrag bis zur Fertigstellung — ist nun um 7.000 $ überhöht. Der Antrag wird abgelehnt.

Dieser Fehler pflanzt sich fort, weil der bestätigte Betrag an einer Stelle existiert (dem unterschriebenen G702 des Architekten), während die Extraktionsquelle — in der Regel die interne Abrechnungstabelle des Subunternehmers oder Generalunternehmers — oft den eingereichten Betrag erfasst. Wenn Sie mehrere Subunternehmer-Zahlungsanträge zu einem einzigen Auszahlungsplan zusammenfassen, wie in unserem Leitfaden zum Zusammenführen von Zahlungsanträgen aus einem gesamten Projekt in einen konsolidierten Auszahlungsplan beschrieben, muss Zeile 7 jedes Subunternehmers einzeln mit der bestätigten Version aus dem vorherigen Zyklus abgeglichen werden. Ein Übertragungsfehler eines Subunternehmers wirkt sich auf den zusammenfassenden G702 des Generalunternehmers aus und wird exponentiell schwerer nachvollziehbar.

6. Die G702-zu-G703-Abstimmung, die niemand bis zur Prüfung überprüft

Jeder Wert in der G702-Zusammenfassung hat einen einzigen Ursprung im G703 — mit einer Ausnahme: Zeile 2, die aus der Tabelle der Änderungsaufträge stammt, die nur im G702 selbst existiert. Dies schafft einen blinden Fleck bei der Abstimmung. Die G703-Summen können perfekt sein, die Änderungsauftragsübersicht kann korrekt sein, und dennoch können beide voneinander abweichen, weil die Änderungsauftragsübersicht unabhängig von den G703-Änderungsauftragspositionen befüllt wurde.

In einem manuellen Workflow ist diese Abstimmung mühsam, aber zumindest zentralisiert — eine Person füllt beide Formulare aus und gleicht sie miteinander ab. In einem Extraktions-Workflow stammen die G703-Summen möglicherweise aus einem KI-Tool, das Subunternehmer-Fortsetzungsblätter liest, während die Änderungsauftragsübersicht aus einem separaten Logbuch des Projektleiters in einem anderen Format stammt. Die beiden Datenströme fließen in denselben G702 ein, wurden aber nie gegeneinander validiert. Das Ergebnis ist ein Formular, bei dem jeder einzelne Abschnitt korrekt validiert, das aber als Ganzes eine nicht behebbare Lücke enthält.

Das ist kein Problem der Extraktionsgenauigkeit, sondern ein Problem dessen, was man Extraktionsarchitektur nennen könnte – also die Frage, welche Quelle welches Ausgabefeld speist und wo im Workflow Querprüfungen stattfinden. Der größte Wert eines Extraktionstools für die G702/G703-Verarbeitung liegt nicht in 99% feldscharfer Genauigkeit (so wichtig diese auch ist). Er liegt darin, die Beziehung zwischen Feldern über Formulare hinweg zu erhalten, sodass eine Zahl aus Seite 3 einer Nachunternehmer-G703 ihre Herkunft bis zu Zeile 4 der G702 des Generalunternehmers zurückverfolgen kann – und bei Abweichungen nachvollziehbar ist.

Der praktische Nutzen: Wenn ein Architekt oder Bauherr eine Zahl hinterfragt, sollten Sie genau sagen können, aus welchem Quelldokument, welcher Position und welcher Spalte diese Zahl stammt – nicht: „Ich schaue kurz in meine Tabelle und melde mich.“ Extraktion ohne Rückverfolgbarkeit ist kaum besser als manuelle Eingabe; sie produziert nur schneller denselben Streitfall.

Aufbau einer Prüfschicht in Ihren Extraktionsworkflow

Keiner der sechs oben genannten Fehler wird durch ein Tool verhindert, das Daten mit hoher Zeichengenauigkeit extrahiert. Es sind strukturelle Fehler – Diskrepanzen zwischen der Bedeutung der Daten im Quellkontext und ihrer Bedeutung im Zielformular. Um sie zu verhindern, braucht es eine Prüfschicht: eine Reihe von Querchecks, die nach der Extraktion, aber vor der Übermittlung durchgeführt werden.

Mindestens sollte diese Ebene prüfen, ob die Summe von Spalte G im G703 dem Wert von Zeile 4 im G702 entspricht, ob der Einbehalt in jeder G703-Zeile dem vertraglichen Satz multipliziert mit Spalte G (nicht Spalte E) dieser Zeile entspricht, ob die Gesamtsumme der Nachtragszusammenfassung im G702 mit der Summe der Nachtragspositionen im G703 übereinstimmt, ob die gelagerten Materialien einer Position deren Sollwert nicht überschreiten und ob Zeile 7 der zertifizierten Zeile 6 des vorherigen genehmigten Antrags entspricht. Dies sind keine komplexen Berechnungen. Es sind Vergleiche, die Sekunden dauern – aber sie müssen in den Arbeitsablauf integriert sein und nicht der Person überlassen werden, die um 23 Uhr am letzten Tag des Abrechnungszeitraums auf „Absenden" klickt.

Für Teams mit einem hohen Antragsvolumen – Generalunternehmer, die monatlich 15 bis 20 Subunternehmer-Zahlungsanträge erhalten – eliminiert die automatisierte Extraktion von AIA G702/G703-Daten in Tabellenkalkulationen den manuellen Eingabeschritt, aber die Prüfebene bleibt unverzichtbar. Die Extraktion bringt die Daten in eine strukturierte Form. Die Prüfebene bestätigt, dass die Struktur in sich schlüssig ist, bevor der Antrag in die Nähe eines Architektenschreibtischs gelangt.

Einige Extraktionstools ermöglichen die Definition berechneter Spalten – Felder, deren Werte aus anderen extrahierten Daten abgeleitet werden, anstatt direkt aus dem Dokument gelesen zu werden. Diese Funktion kann als integrierter Prüfmechanismus dienen. Sie können eine Spalte definieren, die „WENN G703_SpalteG_Summe ≠ G702_Zeile4 DANN ‚FEHLER‘ SONST ‚OK‘" berechnet, und jeden Antrag mit einem Abstimmungsfehler kennzeichnen, bevor er überhaupt in die menschliche Prüfung gelangt. Das Tool muss keine Bauabrechnung verstehen, um diesen Vergleich durchzuführen – es muss nur verstehen, dass zwei extrahierte Werte gleich sein sollen, und Sie warnen, wenn sie es nicht sind.

Häufig gestellte Fragen

Warum wird mein Zahlungsantrag abgelehnt, obwohl die Rechnung stimmt?

Weil korrekte Arithmetik nicht dasselbe ist wie korrekte Daten. Die häufigste Ursache ist eine Diskrepanz zwischen dem, was das Dokument aussagt, und dem, was der Architekt oder der Vertreter des Bauherren aufgrund ihrer unabhängigen Kenntnis des Baufortschritts erwarten. Typische Übeltäter: kumulative Summen, die nicht mit den Beobachtungen vor Ort übereinstimmen, ohne Genehmigung eingefügte Nachtragsaufträge, auf falscher Basis berechnete Sicherheitseinbehalte oder Zeile 7 (frühere Zahlungen), die nicht mit dem letzten zertifizierten Antrag übereinstimmt. Die Rechnung kann perfekt sein, während die Datenherkunft falsch ist.

Was ist der Unterschied zwischen einem G702 und einem G703, und warum ist das für die Extraktion wichtig?

Der G702 ist das zusammenfassende Deckblatt: Er zeigt die Gesamtvertragssumme, Sicherheitseinbehalte, frühere Zahlungen und den aktuell fälligen Betrag auf einer einzigen Seite. Der G703 ist das Fortsetzungsblatt, das den Vertrag in einzelne Positionen aus dem Leistungsverzeichnis aufschlüsselt – eine detaillierte, aufgeschlüsselte Kostenaufstellung. Jede Zahl auf dem G702 (außer der Nachtragsauftragsübersicht) muss auf den G703 zurückführbar sein. Bei der Datenextraktion ist der G703 die Quelle der Wahrheit für positionsgenaue Zahlen; der G702 ist die Zusammenfassung dieser Zahlen. Werden die beiden Formulare unabhängig voneinander statt verknüpft extrahiert, sind Abstimmungsfehler vorprogrammiert.

Kann ein KI-Extraktionstool variable Sicherheitseinbehaltssätze für verschiedene Positionen verarbeiten?

Das hängt vom verwendeten Tool ab. Manche extrahieren nur das, was sichtbar auf der Seite gedruckt ist, und erfassen zuverlässig die Einbehaltsbeträge in Spalte I des G703, können aber nicht prüfen, ob diese Beträge korrekt gemäß Vertrag berechnet wurden. Andere ermöglichen die Definition berechneter Spalten – z. B. eine Spalte namens „Einbehaltsprüfung (Spalte G × 0,10)“, die den erwarteten Einbehalt aus dem kumulierten Gesamtbetrag berechnet und Abweichungen markiert. Dieser Prüfansatz erfasst Fehler, die eine reine Extraktion nicht erkennt, da er den vertraglichen Satz einbezieht, der außerhalb des gelesenen Dokuments liegt.

Welche unterstützenden Unterlagen sollten einer G702/G703-Einreichung stets beiliegen?

Abschnitt 9.3.1 des AIA A201-2017 verlangt, dass Zahlungsanträge von Freigabe- und Verzichtserklärungen für Pfandrechte begleitet werden. Über das rechtliche Minimum hinaus erfordern die meisten Projekte auch geprüfte Lohnabrechnungen (bei öffentlich geförderten Arbeiten), Baufortschrittsfotos, Nachweise über eingelagerte Materialien (Lieferscheine, Lagernachweise) sowie unterschriebene Nachtragsaufträge für alle Arbeiten außerhalb des ursprünglichen Umfangs. Fehlende Unterlagen sind der häufigste verfahrenstechnische Grund für eine Ablehnung – unabhängig von Datenfehlern, aber ebenso schädlich für den Zahlungszeitplan.

Ist es sicher, anhängige Nachtragsaufträge in einen Zahlungsantrag aufzunehmen?

Nein. Die Aufnahme nicht genehmigter Nachtragsänderungen in die G703-Positionen oder in die G702-Nachtragszusammenfassung ist einer der schnellsten Wege, einen Antrag abgelehnt zu bekommen. Gemäß AIA A201-2017 Abschnitt 7.3.9 können Anträge Zahlungsforderungen für Änderungen enthalten, die durch Bauänderungsanordnungen ordnungsgemäß autorisiert, aber noch nicht in Nachtragsänderungen aufgenommen wurden – dies ist jedoch eine enge Ausnahme, keine pauschale Erlaubnis. Der sicherste Ansatz ist, anhängige Nachtragsänderungen in einem separaten Protokoll zu führen und sie erst nach formeller Genehmigung in die G703 zu übernehmen. Die Abrechnung von Arbeiten ohne unterschriebene Autorisierung schafft sowohl einen Vertragsstreit als auch, in vielen Bundesstaaten, ein Problem mit den Pfandrechten.