Welcher Wert gewinnt, wenn
ZATCA-Rechnung XML und PDF nicht übereinstimmen
Eine ZATCA-Steuerrechnung kann SAR 230 inklusive VAT und SAR 126 zahlbar ausweisen, und beide Zahlen können korrekt sein. Die Differenz ist eine bereits erhaltene Anzahlung von SAR 104, die in der XML als Vorauszahlungsbetrag geführt und auf der Seite oft als separate Anzahlungs- oder Saldenzeile dargestellt wird. Eine Tabellenspalte namens „Total" kann nur einen der beiden Werte enthalten. Wird der falsche gebucht, wird der Lieferant für dieselbe Anzahlung doppelt bezahlt.
Das ist die Form der ZATCA-Rechnung XML-Extraktion in der Kreditorenbuchhaltung. Die Datei ist kein einzelnes Dokument. Sie ist eine signierte UBL 2.1-Nutzlast, die den Steuerbeleg trägt, eine PDF/A-3-Seite, die das enthält, was eine Person liest, und einen QR-Code, der eine Zusammenfassung von fünf Geschäftswerten trägt. Sie stimmen dort überein, wo ZATCA sie zur Übereinstimmung ausgelegt hat, und weichen überall dort ab, wo die Kreditorenbuchhaltung operativen Kontext benötigt. Die Arbeit ist eine Zuordnung der Feldautorität plus ein dokumentierter Ausnahmepfad. Ein Parser allein liefert weder das eine noch das andere.

Wichtige Erkenntnisse
- SAR 230 inklusive VAT und SAR 126 zahlbar können beide auf einer ZATCA-Rechnung korrekt sein, weil eine Anzahlung von SAR 104 in der XML steht.
- Die signierte XML ist die Rechnung und die PDF/A-3 ist nur eine Darstellung, sodass die gedruckte Seite abweichen kann, ohne dass einer der beiden Belege falsch ist.
- Extrahieren Sie den angegebenen Zeilennettobetrag und den zahlbaren Betrag als eigene Spalten, und die Abweichung wird zu einer Prüfwarteschlange statt zu einem Zahlungsfehler.
Eine ZATCA-Rechnung sind zwei Datensätze in einem Container

Die signierte XML ist die Rechnung; das PDF/A-3 ist eine Darstellung, die sie enthalten darf. ZATCA, die Zakat, Tax and Customs Authority, verlangt, dass jede Phase-2-Rechnung als ZATCA UBL 2.1 XML oder als PDF/A-3-Datei mit eingebetteter XML erzeugt und gespeichert wird. Die XML ist das Objekt, das signiert wird und dann entweder von ZATCA freigegeben wird, bevor eine Standardrechnung den Käufer erreicht, oder innerhalb von 24 Stunden für eine vereinfachte Rechnung gemeldet wird. Das PDF ist die für Menschen lesbare Kopie.
Die ZATCA Detailed Guidelines for E-Invoicing beantworten die häufige Frage direkt: Wenn ein Steuerpflichtiger ein PDF senden möchte, ist PDF/A-3 mit eingebetteter XML verpflichtend. In Phase 2 ist ein einfaches PDF, eine Word-Datei oder ein Scan überhaupt keine konforme elektronische Rechnung. Die für Menschen lesbare Kopie muss zudem auf Arabisch vorliegen, wobei jede zusätzliche Sprache daneben erlaubt ist. Deshalb kann derselbe Lieferantenname zweimal auftauchen, einmal auf Arabisch und einmal auf Englisch, und deshalb sind die beiden Versionen in einer Abgleichsregel nicht austauschbar.
UBL 2.1 ist der OASIS-XML-Standard, der dem Format zugrunde liegt. Seine Elemente kommen in zwei Familien: cbc für Werte wie ID, IssueDate und TaxAmount sowie cac für Container wie AccountingSupplierParty und InvoiceLine. Die vertrauten Präfixe sind Aliase. Ein Lieferant kann unterschiedliche Präfixnamen für denselben Namespace verwenden, daher sollte ein Parser Namespaces auflösen, statt die Zeichenfolge cbc: abzugleichen. Der ZATCA XML Implementation Standard ergänzt die saudischen Regeln auf UBL und EN 16931.
PDF/A-3 ist eine Archiv-PDF-Variante, die eingebettete Dateien zulässt. Eine Hybridrechnung ist eine normal aussehende Seite plus einen Anhang. Der Anhang ist das, was Sie parsen; die Seite ist das, was eine Person liest. Der QR-Code ist ein dritter, kleinerer Datensatz: eine Base64-Zeichenfolge aus Tag-Length-Value-Datensätzen mit bis zu 500 Zeichen. Die Tags 1 bis 5 enthalten den Verkäufernamen, die Umsatzsteuer-Identifikationsnummer des Verkäufers, den Zeitstempel, die Gesamtsumme inklusive VAT und die VAT-Gesamtsumme; die Tags 6 bis 9 enthalten den Hash, die Signatur, den öffentlichen Schlüssel und bei vereinfachten Rechnungen ZATCAs Signatur über diesen Schlüssel. ZATCAs E-Invoicing-Programm heißt Fatoora (فاتورة).
Ein PDF mit QR-Code ist kein Beweis dafür, dass die XML darin enthalten ist. Die Dateiendung beschreibt den Container, nicht seinen Inhalt. Prüfen Sie die Anhangssammlung, bevor Sie entscheiden, welchen Datensatz Sie lesen.
Was tatsächlich in einem AP-Postfach ankommt
Die Dateiendung verrät Ihnen fast nichts; die Anhänge zeigen Ihnen, was Sie parsen können. Das ERP eines Lieferanten kann ein korrektes Hybrid erzeugen, und der Käufer erhält trotzdem ein flach gerendertes PDF. Beschaffungsportale rendern Anhänge neu, E-Mail-Gateways entfernen sie, und AP-Sachbearbeiter drucken vor dem Ablegen in PDF. Die Rechnung im Postfach kann perfekt aussehen und strukturell leer sein. Der Jahresbericht 2025 von ZATCA beziffert das E-Rechnungsvolumen des Jahres auf über 8 Milliarden, ein gemischtes Postfach ist also kein Sonderfall. Die vier folgenden Zustände erfordern unterschiedliche Behandlung.
| Was angekommen ist | Was Sie parsen können | Erste Prüfung | Vertrauensstufe |
|---|---|---|---|
Rohe .xml | Die Rechnungsnutzlast selbst | Wohlgeformt, Root Invoice, erwartete Namespaces, Prüfsumme der empfangenen Bytes | Geparst |
| PDF/A-3 mit zugänglichem XML-Anhang | Die eingebettete Nutzlast | Anhang öffnet sich, parst als XML, und die Seite stimmt mit den stichprobenartig geprüften Werten überein | Geparst |
| PDF/A-3 ohne nutzbaren XML-Anhang | Pixel, keine Zeichen, wenn die Seite nur aus Bild besteht | Anhang fehlt, ist beschädigt oder unlesbar; Text ist möglicherweise nicht auswählbar | Beobachtet |
| Einfaches PDF, JPG oder PNG | Auswählbarer Text oder Pixel | Kein Anhang; ein QR-Code kann dennoch auf der Seite gedruckt sein | Beobachtet |

Das Umgekehrte kommt ebenfalls vor. Im Entwicklerforum von ZATCA gibt es einen Thread eines Lieferanten, der fragt, ob Werte als Bild in einem PDF/A-3 übermittelt werden können. Die Datei erklärt die Konformität, aber die Zeichen lassen sich weder auswählen noch kopieren, weil es keine Schriften gibt, nur Pixel. In diesem Fall ist das eingebettete XML die einzige maschinenlesbare Ebene, und OCR wird zum Fallback statt zur Standardmethode. Der Forumsthread ist eine nützliche Erinnerung daran, dass „PDF/A-3" den Container beschreibt, nicht die Lesbarkeit der Seite.
Prüfen Sie den Anhang, nicht den Dateinamen. Öffnen Sie das Anhänge-Panel in einem PDF-Reader oder prüfen Sie den /AF-Eintrag, extrahieren Sie die Datei in einen kontrollierten Arbeitsordner, bestätigen Sie, dass sie als XML parst, und lassen Sie die Originalbytes unangetastet. Wenn der Anhang fehlt, beschädigt oder unzugänglich ist, halten Sie diesen Zustand fest, bevor Sie die Seite verwenden. Die vier oben genannten Zustände sind nicht gleichwertig, und eine beobachtete Seite wie eine geparste Nutzlast zu behandeln, ist die erste Stelle, an der eine AP-Ausnahme verloren geht.
Die Felder, die über die Zahlung entscheiden
AP benötigt etwa ein Dutzend Kopffelder und fünf pro Position, und das XML benennt jedes einzelne davon. Sobald das Artefakt triagiert ist, bleibt die Feldliste dieselbe, egal ob die Werte aus einem Parser oder einer Seite stammen. Die Tabelle ist eine Arbeitskarte, kein vollständiges Datenwörterbuch. Sie enthält die Felder, die eine Zahlung, eine Steuerbuchung oder eine Dublettenprüfung verändern, und lässt die weg, die nur für die Freigabe des Verkäufers relevant sind. Pfade sind relativ zum Invoice-Root.
| AP-Feld | UBL-Pfad | PDF zeigt üblicherweise | Quelle |
|---|---|---|---|
| Rechtlicher Name des Lieferanten | cac:AccountingSupplierParty/cac:Party/cac:PartyLegalEntity/cbc:RegistrationName | Zweisprachiger Namensblock | XML |
| USt-IdNr. des Verkäufers | .../cac:PartyTaxScheme/cbc:CompanyID | 15 Ziffern, beginnt und endet mit 3 | XML, Abgleich QR-Tag 2 |
| Rechtlicher Name und USt-IdNr. des Käufers | cac:AccountingCustomerParty/... | Käuferblock; bei vereinfachten Rechnungen optional | XML |
| Rechnungsnummer | cbc:ID | Obere Ecke oder Kopfzeile | XML |
| UUID | cbc:UUID | Häufig nicht gedruckt | Nur XML |
| Ausstellungsdatum und -zeit | cbc:IssueDate, cbc:IssueTime | Datum, selten die Uhrzeit | XML |
| Rechnungstyp | cbc:InvoiceTypeCode und dessen name-Attribut | "Tax Invoice" oder "Simplified" | XML |
| Währung und Steuerwährung | cbc:DocumentCurrencyCode, cbc:TaxCurrencyCode | Währungssymbol oder -code | XML |
| Bestellung, Lieferschein, Fälligkeitsdatum | cac:OrderReference/cbc:ID, cac:Delivery, cac:PaymentTerms | Üblicherweise gedruckt | Seite, wenn XML sie auslässt |
| Positionsmenge und Einheit | cac:InvoiceLine/cbc:InvoicedQuantity und unitCode | Mengenspalte | XML |
| Einzelpreis und Basismenge | cac:InvoiceLine/cac:Price/cbc:PriceAmount, cbc:BaseQuantity | Einzelpreisspalte | XML |
| Positionsrabatt oder -zuschlag | cac:InvoiceLine/cac:AllowanceCharge/cbc:Amount | Rabattspalte oder Fußnote | XML |
| Angegebener Positionsnettobetrag | cac:InvoiceLine/cbc:LineExtensionAmount | Positionssumme | XML |
| USt-Kategorie und -Satz der Position | cac:InvoiceLine/cac:Item/cac:ClassifiedTaxCategory/cbc:ID (S, Z, E oder O) und cbc:Percent | "15%", "Zero-rated" oder "Exempt" | XML |
| Steuer und Summen | cac:TaxTotal/cbc:TaxAmount; cac:LegalMonetaryTotal | Zwischensumme, USt, Gesamtbetrag, fälliger Betrag | XML, Seite zur visuellen Prüfung |
| Gutschriftreferenz | cac:BillingReference/cac:InvoiceDocumentReference/cbc:ID | "Against invoice ..." | XML |
Zwei Regeln machen die Karte nutzbar. Extrahieren Sie LineExtensionAmount und PayableAmount als eigene Spalten, auch wenn Sie zusätzlich Menge und Preis extrahieren. Einen Wert neu zu berechnen, den das Dokument bereits angibt, ist der Weg, auf dem AP eine Abweichung erzeugt, die es nicht gibt. Behalten Sie außerdem die Rohzeichenkette neben dem normalisierten Wert. Eine Rechnungsnummer mit führender Null, ein arabischer Firmenname und ein Zeitstempel in Arabia Standard Time verlieren alle Informationen, wenn sie zu früh vereinheitlicht werden. Arabische Namen können zudem in einer anderen visuellen Reihenfolge erscheinen, selbst wenn die Zeichen korrekt sind – behalten Sie daher die Rohzeichenkette und legen Sie die Anzeigerichtung fest, statt den Wert neu zu tippen. Wenn die Aufteilung in Kopf und Position für Sie neu ist, behandelt der vollständige Leitfaden zur Rechnungsdatenextraktion das allgemeine Modell.
Wo die beiden Ebenen tatsächlich voneinander abweichen

Die meisten Abweichungen sind keine Beschädigungen. Es sind zwei korrekte Darstellungen unterschiedlicher Felder. Die fünf Fälle unten erklären die meisten AP-Ausnahmen, die wie Datenfehler aussehen, in Wahrheit aber Zuordnungsfehler sind.
Ein Positionsrabatt ändert das Positionsnetto, nicht den Einzelpreis
Der Implementierungsstandard von ZATCA definiert das Positionsnetto als ((Nettopreis des Artikels ÷ Basismenge) × in Rechnung gestellte Menge) minus Positionsrabatt plus Positionszuschlag. Eine Position mit 10 Einheiten zu SAR 100 und einem Positionsrabatt von SAR 50 hat ein Positionsnetto von SAR 950, während der ausgewiesene Einzelpreis SAR 100 bleibt. Wenn die PDF den Einzelpreis und die Positionssumme zeigt, aber nicht den Rabatt, wirkt die Seite rechnerisch falsch. Das ist sie nicht. Der Rabatt steht in der XML, in cac:InvoiceLine/cac:AllowanceCharge.
Wenn AP Menge und Einzelpreis extrahiert und eine Positionssumme berechnet, erhält es SAR 1.000 gegenüber einem Dokument, das SAR 950 ausweist. Die Rechnung scheitert dann an einer Prüfung, die sie hätte bestehen müssen, oder ein Sachbearbeiter korrigiert das falsche Feld, damit es aufgeht. Extrahieren Sie das angegebene Positionsnetto und führen Sie den Rabatt in einer eigenen Spalte, damit die Rechnung später nachvollzogen werden kann.
Eine berechnete Spalte ist zum Prüfen nützlich. Sie ersetzt nicht das Positionsnetto, das das Dokument angibt.
Eine Vorauszahlung teilt den Gesamtbetrag in zwei Zahlen
ZATCAs eigenes Vorauszahlungsbeispiel zeigt das Muster: SAR 230 inklusive VAT, SAR 104 bereits vorausbezahlt, SAR 126 zahlbar. TaxInclusiveAmount ist 230, PrepaidAmount ist 104, PayableAmount ist 126. Alle drei sind korrekt, und jede beantwortet eine andere Frage. Ordnen Sie den fälligen Betrag PayableAmount zu, den Rechnungswert TaxInclusiveAmount und die Vorauszahlung einer eigenen Spalte. Wenn das ERP nur ein einziges Gesamtbetragsfeld hat, tragen Sie dort den Rechnungswert ein und führen den zahlbaren Betrag im Zahlungsplan. Wenn Sie eines mit dem anderen überschreiben, wird die Vorauszahlung verdeckt und doppelt bezahlt.
Eine Fremdwährungsrechnung trägt zwei Steuersummen
Wenn die Dokumentwährung nicht SAR ist, verlangt ZATCA, dass TaxCurrencyCode SAR ist und eine zweite Steuersumme in SAR angegeben wird. Die PDF druckt oft nur die Dokumentwährung. Ein AP-Team, das den ausgewiesenen Gesamtbetrag mit einem Monatsendkurs umrechnet, erhält einen anderen SAR-VAT-Betrag als den in der XML, und die Differenz landet im VAT-Vorsteuerkonto. Lesen Sie beide Steuersummen, buchen Sie die in SAR und behalten Sie die in der Dokumentwährung für das Lieferantenkonto.
Die PDF kann Felder enthalten, die im XML nicht vorgeschrieben sind
Der ZATCA-Standard ist ein Minimum. Im Fatoora-Entwicklerforum fragte ein Lieferant, ob zusätzliche Informationen, die auf der PDF/A-3 gedruckt werden, im XML erscheinen müssen. Die Antwort lautete, dass Felder außerhalb des Datenwörterbuchs nicht im XML erforderlich sind, aber hinzugefügt werden dürfen, wenn sie UBL entsprechen. Dort stehen häufig Bestellnummern, Lieferscheinreferenzen, interne Kostenstellen und Genehmigungsstempel. Sie stehen auf der Seite, nicht in der Nutzlast.
Für eine reine XML-Pipeline ist das eine Lücke. Der Drei-Wege-Abgleich benötigt die Bestellung, und die Zahlungsplanung benötigt das Fälligkeitsdatum. Das XML enthält cac:OrderReference und cac:PaymentTerms, aber ein Lieferant ist nicht verpflichtet, sie auf jeder Rechnung zu befüllen. Das praktische Design ist eine quellenbezogene Spalte auf Feldebene: Steuern und Identität aus dem XML, operativer Kontext von der Seite und ein expliziter Status „nicht vorhanden", wenn keines von beiden ihn enthält.
Eine Gutschrift ist ein neues Dokument, keine negative Rechnung
Eine Gutschrift verwendet den Rechnungstypcode 381, trägt eine Abrechnungsreferenz auf die Rechnung, die sie korrigiert, gibt einen Grund an und behält in der Regel positive Beträge, da der Dokumenttyp die Richtung trägt. Buchen Sie sie als negative Eingangsrechnung, kann das Vorzeichen zweimal umgedreht werden: einmal durch den Typ, einmal durch Ihre Buchung. Das Ergebnis ist eine Gutschrift, die den Saldo erhöht.
Verrechnen Sie die Gutschrift mit der referenzierten Rechnung und prüfen Sie, ob die Referenz aufgelöst werden kann. Die ZATCA-Richtlinie erlaubt, dass eine Gutschrift mehrere Originalrechnungen als Textbereich referenziert, sodass die Referenz nicht immer ein einzelner Schlüssel ist. Wenn sie ein Bereich ist, teilen Sie die Gutschrift auf oder halten Sie sie zurück, bis der Lieferant eine Aufschlüsselung pro Rechnung liefert.
Die folgende Tabelle macht die gängigen Fälle zu einem Routing-Blatt.
| Symptom | Übliche Ursache | Zuständig |
|---|---|---|
| XML-Summe weicht von der gedruckten Summe ab | Positionsrabatt oder Vorauszahlung dem falschen Feld zugeordnet | Kreditorenbuchhalter, mit dem ERP-Verantwortlichen für die Zuordnung |
| Verkäufer-USt weicht von QR-Tag 2 ab | Falscher Anhang, veraltetes Rendering oder Fehler bei der Dokumentzusammenstellung | ERP- oder Integrationsverantwortlicher |
| SAR-USt weicht vom Hauptbuch ab | Gedruckte Summe umgerechnet statt der SAR-Steuersumme aus dem XML | Leiter Steuern oder Compliance in Saudi-Arabien |
| Bestellung oder Fälligkeitsdatum fehlt | Feld nur auf der PDF oder in beiden Datensätzen nicht vorhanden | Kreditorenbuchhalter, dann der Lieferant |
| Gutschrift lässt sich nicht zuordnen | Abrechnungsreferenz ist ein Bereich oder verweist auf eine ersetzte Rechnung | Kreditorenbuchhalter, mit dem Steuerverantwortlichen |
| Anhang lässt sich nicht öffnen | Portal hat die PDF neu gerendert oder ein PDF/A-3-Konformitätsproblem | ERP- oder Integrationsverantwortlicher |
Der QR-Code ist eine Konsistenzprüfung, kein Freigabezertifikat
Wenn ein QR-Code zur Seite passt, beweist das nur, dass beide aus denselben Werten erzeugt wurden; es beweist nicht, dass die Rechnung freigegeben wurde. Tag 1 bis 5 sind die einzigen Geschäftswerte im Code. Es gibt keine Rechnungsnummer, keine Rechnungsposition, keine Bestellnummer und keine USt-IdNr. des Käufers. Ein QR-Code ist eine Zusammenfassung, und eine kurze.
Als Eingangsprüfung sind Tag 1 bis 5 dennoch nützlich. Normalisieren Sie vor dem Vergleich: die USt-IdNr. als Ziffern, den Zeitstempel als Zeitpunkt, denn Arabia Standard Time und UTC können denselben Moment beschreiben, und die Beträge auf zwei Dezimalstellen. Eine Abweichung bedeutet meist, dass der QR-Code zu einer anderen Rechnung gehört oder dass die Seite nach der Erzeugung des Codes neu aufgebaut wurde. Beides ist ein Grund anzuhalten.
Tag 6 bis 9 lassen sich weder mit dem Auge noch mit einem Handy-Scanner prüfen. Ihre Verifikation erfordert das signierte XML, die exakte Byte-Form, über die die Signatur berechnet wurde, die Zertifikatskette und eine Sperrabfrage. Ein Scan, der neun Felder anzeigt, hat neun Felder angezeigt. Er hat die Signatur nicht verifiziert.
AP-Teams hören dazu Unterschiedliches. Im Fatoora-Entwicklerforum schrieb ein AP-Praktiker: „Das ZATCA-Supportteam sagt, es sei Pflicht, die QR-Codes für Lieferantenrechnungen zu scannen. Ich stelle meine Frage aus Sicht der Kreditorenbuchhaltung." Die Antwort des Community-Leads war, dass das Scannen eine optionale Prüfung sei und dass eine erfolgreich gemeldete oder freigegebene Rechnung die E-Invoicing-Anforderungen bereits erfüllt. Im selben Thread steht, dass die ZATCA-App Codes außerhalb Saudi-Arabiens nicht scannen kann, was für ein Shared Service Center in einem anderen Land ein praktisches Problem ist.
Die praktikable Haltung: Nutzen Sie den QR-Code als Stichprobenkontrolle und als Prüfung der Anhangsintegrität. Machen Sie ihn nicht zum Gate pro Rechnung, und behandeln Sie einen Scan nicht als Freigabenachweis. Der Nachweis ist das freigegebene oder gemeldete XML, aufbewahrt mit seiner Antwort.
Ein kopierter QR-Code kann auf einer manipulierten Seite stehen. Vergleichen Sie die Werte; behandeln Sie das Quadrat nicht als Beweis.
Ein sechsstufiger Workflow, der auch Ausnahmen übersteht
Der Workflow für die Kreditorenbuchhaltung mit saudischen E-Rechnungen muss eine Zeile pro Rechnungsposition erzeugen, eine Quellenkennzeichnung für jedes Feld und einen Ausnahmestatus, den niemand stillschweigend überschreiben kann. Die Schritte sind bewusst unspektakulär. Unspektakulär ist es, was die Ausgabe auch sechs Jahre später noch belastbar macht.
Das Artefakt triagieren
Prüfen Sie die Anhangssammlung, bevor Sie die Seite lesen. Erfassen Sie einen von vier Quellzuständen: reines XML, Hybrid mit zugänglichem XML, Hybrid mit einer reinen Bildseite oder reines PDF bzw. Scan. Hashen Sie das Original und bewahren Sie es auf. Der Quellzustand entscheidet, wie die nächsten beiden Schritte ausgeführt werden.
Den Header einmal extrahieren
Rechnungsnummer, UUID, Typcode, Ausstellungsdatum und -zeit, USt-Identifikatoren von Verkäufer und Käufer, Währung und Steuerwährung. Halten Sie die UUID getrennt von der Rechnungsnummer. Die eine identifiziert das Dokument im System von ZATCA, die andere in den Büchern des Lieferanten, und Dublettenprüfungen benötigen beides.
Die Positionen aufschlüsseln
Eine Zeile pro cac:InvoiceLine: Positions-ID, Menge und unitCode, Preis und BaseQuantity, Zu- oder Abschlag, angegebener Positionsnettobetrag, VAT-Kategorie und -Satz, Positionssteuer. Kopieren Sie keine Header-Summen auf jede Zeile, ohne die Körnung zu kennzeichnen, sonst zählt eine spätere Summe dieselbe Summe einmal pro Zeile.
Eine schmale Auswahl vergleichen
Verkäufer-USt, Zeitstempel, Gesamtbetrag inklusive USt und USt-Gesamtbetrag, über XML, Seite und QR-Code hinweg. Führen Sie dann vier arithmetische Prüfungen durch: die Positionsnettobetragsformel, die Summe der Positionen gegen LineExtensionAmount, TaxExclusiveAmount plus Steuer gegen TaxInclusiveAmount und TaxInclusiveAmount minus Vorauszahlung plus Rundung gegen PayableAmount.
AP-Kontrollen separat anwenden
Lieferantenstamm, Dublettenprüfung anhand von Lieferanten-USt plus Rechnungsnummer plus UUID, Bestell- und Wareneingangsabgleich, Vorsteuerabzug, Genehmigungsbefugnis. Eine geparste Rechnung ist keine genehmigte Rechnung. Halten Sie die Kontrollen in eigenen Status, damit ein Parse-Fehler nicht wie eine kaufmännische Ablehnung aussieht.
Das Original und den Datensatz archivieren
Bewahren Sie den unveränderten XML- oder PDF/A-3-Container, den Clearance- oder Reporting-Nachweis, den Extraktionsdatensatz und die Ausnahmehistorie zusammen auf. Die Tabelle verweist auf das Artefakt. Sie ersetzt es nicht, und sie kann keine Signatur reproduzieren.
Drei Verantwortliche, drei Fragen. Die Kreditorenbuchhaltung verantwortet den kaufmännischen Abgleich und die Lieferantenrückfrage. Der ERP- oder Integrationsverantwortliche verantwortet den Anhang, den Namespace und den Parser. Die saudische Steuerverantwortung verantwortet die VAT-Kategorie, den Clearance-Nachweis und die Aufbewahrungsentscheidung. Ein einzelnes „gültig“-Flag fasst diese Antworten zu einer zusammen und verbirgt, welches Team handeln muss. Speichern Sie die Zustände getrennt: geparst, Schema fehlgeschlagen, Werte weichen ab, kryptografischer Nachweis unbestätigt, AP-Sperre, zur Zahlung freigegeben.
Was visuelle Extraktion hier leisten kann und was nicht
Ein visuelles Extraktionstool liest die Seite, nicht den Anhang, und gehört daher auf die PDF-Seite dieses Workflows. Das ist der Teil, den ImageToTable.ai abdeckt, und es ist eine engere Rolle als „ZATCA-Rechnungsextraktion“. An drei Stellen ist es dennoch nützlich.
Erstens bei Feldern, die nur auf dem PDF existieren. Wenn das ERP das XML parst, ist die Seite möglicherweise immer noch der einzige Ort, an dem die Bestellnummer, der Lieferschein oder die interne Freigabe erscheint. Mit Custom Column Extraction geben Sie die gewünschten Spaltennamen ein, etwa „PO Number“, „Payment Due Date“ und „Delivery Note“, und das Modell findet die Werte über die Bedeutung statt über feste Koordinaten. Die von Ihnen eingegebenen Spaltennamen werden zu den Kopfzeilen der Ausgabetabelle.
Zweitens bei der Ausnahme ohne XML. Wenn ein Lieferant ein reines PDF oder ein reines Bild-PDF/A-3 sendet, gibt es nichts zu parsen. Die Seite wird zur Quelle. Die Batch-Verarbeitung bewältigt einen Ordner mit gemischten Lieferantenlayouts in einem Durchgang und führt die Zeilen in einer Tabelle zusammen – das ist der Unterschied zwischen einer handhabbaren Ausnahmewarteschlange und einem Haufen Einzelkonvertierungen.
Drittens beim visuellen Vergleich. Review Mode mit Bbox-Hervorhebung lässt Sie über eine Zelle fahren und den Bereich auf der Originalseite sehen, der sie erzeugt hat, und auf einen Bereich klicken, um zur Zelle zurückzuspringen. Bei einer ZATCA-Rechnung vergleicht eine Sachbearbeitung so den gedruckten zahlbaren Betrag mit dem XML-Wert, ohne die Seite auszudrucken und ein Lineal zu benutzen. Der ursprüngliche Wert der KI bleibt erhalten und kann wiederhergestellt werden, wenn eine Bearbeitung falsch war. Bei reinen Bildscans und dichten zweisprachigen Layouts nutzt eine höhere Model Tier ein stärkeres Vision-Modell. Standard deckt die meisten gedruckten Tabellen ab; der schwierige Fall ist ein gescannter Ausdruck mit kleinem arabischem Text und einem Stempel über der Summe.
Die Grenzen sind ebenso wichtig. Es öffnet nicht das eingebettete XML, validiert nicht den kryptografischen Stempel, prüft nicht den QR-Hash, bindet keinen Lieferanten an ZATCA an und reicht nichts ein. Eine visuelle Extraktion eines PDF/A-3 ist eine Beobachtung der gerenderten Seite, kein Parsen der signierten Nutzlast. Kennzeichnen Sie es in der Ausgabe entsprechend. Wenn die Seite einen Zeilenrabatt auslässt, wird die Beobachtung ihn ebenfalls auslassen, und die arithmetische Prüfung in Schritt 4 ist es, die die Abweichung aufdeckt.
Dieselbe Unterscheidung gilt in anderen Märkten. Japans qualifiziertes Rechnungssystem hat keine vorgeschriebene XML-Nutzlast, sodass die visuelle Ebene oft die einzige Quelle ist – weshalb dieselbe Disziplin auch für japanische qualifizierte Rechnungen gilt. Das deutsche Mandat macht die strukturierte Datei zur Rechnung, was die Erfassungsreihenfolge für deutsche Lieferantenrechnungen ändert. Ein Team, das beides bearbeitet, braucht eine Feldzuordnung und zwei Erfassungsregeln.
Das Archiv ist Teil der Extraktion
Die Tabelle ist nicht die Rechnung, und eine PDF allein ist nicht der Nachweis, den ein Prüfer validieren kann. Article 66 der saudi-arabischen VAT Implementing Regulations verlangt, dass Rechnungen, Bücher, Aufzeichnungen und Buchhaltungsunterlagen mindestens sechs Jahre ab dem Ende des Steuerzeitraums, auf den sie sich beziehen, aufbewahrt werden. Aufzeichnungen über Anlagevermögen laufen für den Anpassungszeitraum nach Article 52 plus fünf Jahre, also 11 Jahre für bewegliche und 15 Jahre für unbewegliche Wirtschaftsgüter. Die Aufzeichnungen müssen in Arabisch vorliegen und im Königreich gespeichert werden, elektronisch oder physisch, mit Zugriff von einem Terminal im Königreich.
Bewahren Sie das empfangene XML oder den unveränderten PDF/A-3-Container auf, nicht nur eine extrahierte Kopie des Anhangs. Bewahren Sie die Clearance- oder Reporting-Antwort für Standardrechnungen auf, denn das ist der Nachweis, dass die Rechnung akzeptiert wurde. Halten Sie den Rechnungszähler und die vorherige Hash-Kette intakt; eine Lücke ist selbst ein Beweis. Bewahren Sie Gutschriften zusammen mit den Rechnungen auf, die sie korrigieren, da eine Änderung unzulässig ist.
Der Extraktionsdatensatz hat eigene Felder: Hash der Quelldatei, Quelltyp, Parser- oder Modellversion, Regelwerk-Version, feldspezifische Quelle, normalisierter Wert, Rohwert und Ausnahmestatus. Ein erneutes Ausführen eines Parsers oder Modells erfordert später dieselben Bytes. Wenn Sie das Original mit einem normalisierten Wert überschreiben, haben Sie den Beweis zerstört, den Sie zur Verteidigung der Zeile bräuchten.
Andere Clearance-Modelle machen denselben Punkt. Polens KSeF-System vergibt eine Kennung, ohne die die Rechnung rechtlich nicht existiert, und Mexikos CFDI-Rechnungen kombinieren eine strukturierte Datei mit einer druckbaren Darstellung. In jedem Fall ist das Archiv das strukturierte Artefakt plus die Antwort der Behörde, nicht die PDF.
Häufig gestellte Fragen
Kann ich Positionen aus einem ZATCA QR-Code extrahieren?
Nein. Tag 1 bis 5 enthalten den Verkäufernamen, die Umsatzsteuer-Identifikationsnummer des Verkäufers, den Zeitstempel, den Gesamtbetrag inklusive VAT und den VAT-Gesamtbetrag. Es gibt keine Rechnungsnummer, keine Käuferkennung und keine Positionsdetails. Nutzen Sie den Code zum Abgleich dieser fünf Werte, nicht zum Aufbau einer Positionstabelle.
Ist jede PDF/A-3-Rechnung ein Hybrid mit XML darin?
Nein. PDF/A-3 ist ein Container, der eingebettete Dateien zulässt; er garantiert nicht, dass der Lieferant eine dort abgelegt hat, dass der Anhang lesbar ist oder dass die Seite daraus erzeugt wurde. Öffnen Sie die Anhangssammlung und parsen Sie die Datei, bevor Sie das PDF als strukturierte Quelle behandeln.
Welchen Gesamtbetrag buche ich, wenn eine Rechnung eine Vorauszahlung enthält?
Buchen Sie den Rechnungswert aus TaxInclusiveAmount und zahlen Sie den fälligen Betrag aus PayableAmount. Führen Sie PrepaidAmount in einer eigenen Spalte und verknüpfen Sie ihn mit der Vorauszahlungsrechnung. Fassen Sie die drei nicht zu einem einzigen Feld „Gesamtbetrag" zusammen und überschreiben Sie nicht den Rechnungswert mit dem zahlbaren Betrag.
Ist die PDF/A-3 die rechtliche Rechnung?
Nein. Die signierte XML ist die Rechnung. Die PDF/A-3 ist die menschenlesbare Kopie, die sie tragen darf. Halten Sie bei einer Standardrechnung die freigegebene XML oder den freigegebenen Hybrid vor und archivieren Sie den Container statt eines erneut gespeicherten PDF.
Kann ich OCR auf einer ZATCA-Rechnung verwenden?
Ja, wenn keine nutzbare XML vorhanden ist. Ein reines Bild-PDF, ein Scan oder ein Foto können visuell gelesen werden, aber das Ergebnis ist eine Beobachtung der Seite, kein Parse der signierten Nutzlast. Dokumentieren Sie die Methode, führen Sie dieselben Normalisierungs- und Arithmetikprüfungen durch und gleichen Sie die fünf Werte des QR-Codes ab, sofern lesbar.
Wie gehe ich mit einer Gutschrift um, die auf mehrere Rechnungen verweist?
Behandeln Sie sie als neues Dokument mit Typ 381 und einer BillingReference, nicht als negative Eingangsrechnung. Wenn die Referenz ein Bereich ist, teilen Sie die Gutschrift auf die ursprünglichen Rechnungen auf oder halten Sie sie zurück, bis der Lieferant eine Aufschlüsselung pro Rechnung liefert. Verrechnen Sie sie mit den Rechnungen, die sie korrigiert, und archivieren Sie sie gemeinsam mit diesen.
Parst ImageToTable.ai das eingebettete UBL XML oder verifiziert es den QR-Code?
Nein. Es liest die PDF-Seite, das Bild oder den Scan und extrahiert die von Ihnen definierten Spalten, einschließlich Felder, die nur auf der gedruckten Seite existieren. Es öffnet nicht den eingebetteten XML-Anhang, validiert nicht den kryptografischen Stempel, verifiziert nicht den QR-Hash, bindet keinen Lieferanten an ZATCA an und übermittelt keine Meldung. XML-Parsing und Signaturprüfung gehören zu Ihrem ERP oder Ihrer Integrationsschicht.
Wie lange muss eine saudische Lieferantenrechnung aufbewahrt werden?
Mindestens sechs Jahre ab dem Ende des Steuerzeitraums, auf den sie sich bezieht, gemäß Article 66 der VAT Implementing Regulations. Aufzeichnungen über Anlagevermögen laufen über den Anpassungszeitraum plus fünf Jahre, also 11 Jahre für bewegliche und 15 für unbewegliche Wirtschaftsgüter. Bewahren Sie das XML oder den unveränderten PDF/A-3-Container, den Clearance- oder Reporting-Nachweis und die Gutschriften zusammen auf.
Die Zeile, die der Prüfung standhält
Die Rechnung, die ein Audit übersteht, ist die, bei der jede Zeile das Feld benennen kann, aus dem sie stammt, das Artefakt dahinter und die Prüfung, die sie durchgelassen hat. Sobald diese Zuordnung existiert, ist die Abweichung zwischen PDF und XML kein Rätsel mehr, sondern eine Warteschlange mit einem Verantwortlichen.