Rechnungen prüfen: Rechensperre vor DeepSeek

Die Zeilen nachrechnen, bevor DeepSeek sie erläutert

Eine Veranstaltungsrechnung kann rechnerisch stimmig aussehen und trotzdem einen Fehler enthalten. Im folgenden Beispiel ergeben die drei angegebenen Positionen des Lieferanten insgesamt $234.00, genau wie der ausgewiesene Rechnungsbetrag. Eine Position berechnet jedoch $80.00 für zwei Einheiten zu je $45.00. Menge mal Einzelpreis ergibt $90.00; die unabhängig berechnete Gesamtsumme beträgt damit $244.00. Zwei übereinstimmende, übernommene Summen sind keine unabhängige Prüfung.

Dieser Leitfaden gibt Veranstaltungskoordinatoren ein ausführbares Python-Prüfprogramm, das diese Abweichung erkennt, bevor eine Anfrage an DeepSeek V4.1 Flash vorbereitet wird. Das konkrete Ergebnis sind ein positionsbezogener Abweichungsbericht und ein kleines Briefing für einen Textentwurf, das das Programm erst nach bestandener Rechenprüfung erstellt. Alle Beispiele sind erfundene Konferenzausgaben; die Ergebnisse stammen aus dem lokal ausgeführten Programm. Kein Modell hat hier eine Rechnung erzeugt oder genehmigt.

Nachdem ein Mensch die Abweichung geklärt hat, kann DeepSeek optional beim Formulieren helfen. Es soll weder den vereinbarten Lieferantenpreis bestimmen noch eine Zahlung freigeben oder eine Rechnung unbemerkt ersetzen. Originalbeleg, Vertrag und Rückfrage bleiben die Belege für diese Entscheidung. Eine korrekte Multiplikation belegt einen rechnerischen Zusammenhang, aber weder die Leistungserbringung noch die Genehmigung eines Entgelts.

Abbildung: synthetischer Testfall in USD, kein echter Lieferantenbeleg.

Die Abweichung von $10 hinter einer passenden Gesamtsumme

Der synthetische Export umfasst Namensschilder, Raumbeschilderung und Untertitelungsleistungen. Die Mengen bestehen aus ganzen Leistungseinheiten. Das Prüfprogramm verwendet für jede Zeile dasselbe Schema mit fünf Spalten und zusätzlich eine separat übergebene Rechnungssumme. Dieser separate Wert ist wichtig: Eine Summe mit sich selbst zu vergleichen, wäre erneut eine beruhigende, aber nutzlose Prüfung.

Horizontal wischen, um die ganze Tabelle zu sehen.

Daraus folgt nicht automatisch, dass $10 zu wenig bezahlt werden. Vielleicht sollte die Position rabattiert sein; vielleicht ist die Menge oder der Einzelpreis falsch. Das Programm kann nicht zwischen diesen Erklärungen entscheiden. Sein Befund ist enger und hilfreicher: L3 erfüllt die festgelegte Regel Menge mal Einzelpreis nicht. Die Rechnung muss deshalb geklärt werden, bevor dieser Ablauf ein gewöhnliches Textbriefing erstellt.

Bewahren Sie beide Fassungen auf, wenn der Lieferant den Export korrigiert. Der korrigierte Testdatensatz weiter unten ändert L3 auf USD 90.00 und zugleich die Gesamtsumme auf USD 244.00. Das ist eine bewusst konstruierte Reparatur für den Test, keine Aussage über die Absicht eines echten Lieferanten. Bei einer tatsächlichen Rechnung benötigt die prüfende Person weiterhin die tatsächlich genehmigte Korrektur.

Ein Geldformat festlegen, statt die Gebietskonvention zu erraten

Der Code akzeptiert nichtnegative USD-Beträge mit genau zwei Nachkommastellen sowie positive ganze Mengen. Er wandelt Betragszeichenfolgen in ganzzahlige Cent um und verwendet anschließend ganzzahlige Multiplikation und Addition. Es gibt weder binäre Gleitkommavergleiche noch eine Toleranz, die einen Cent Unterschied verdecken könnte. Das ist ein bewusst kleiner Eingabevertrag, kein universeller Rechnungsparser.

Beträge wie 2.500, -2.50, 234,00 und wissenschaftliche Schreibweise werden abgelehnt. Auch führende oder nachgestellte Leerzeichen in Zahlenfeldern sind nicht erlaubt. Ein europäischer Export ist nicht deshalb falsch, weil er andere Konventionen verwendet. Vor diesem speziellen Prüfer braucht er einen gesonderten, überprüften Normalisierungsschritt. Raten Sie nicht, ob ein Trennzeichen Dezimalstellen oder Tausendergruppen kennzeichnet.

Die CSV-Dokumentation von Python erläutert unterschiedliche Trennzeichen und Anführungsregeln. Das Programm verwendet den CSV-Parser, statt Zeilen an jedem Komma aufzuteilen, und öffnet den Datenstrom im Arbeitsspeicher mit der dokumentierten Zeilenumbruchbehandlung. Eine in Anführungszeichen gesetzte Beschreibung mit Komma kann dadurch ein einziges Feld bleiben. Unerwartete Spalten und doppelte Positionskennungen werden abgewiesen, statt stillschweigend ignoriert zu werden.

Bruchteile von Mengen, Steuern, Rabatte, Versand, mehrere Währungen und Gutschriften liegen außerhalb dieses Vertrags. Enthält eine Rechnung solche Bestandteile, halten Sie an und definieren Sie zuerst die dazugehörigen Rechenregeln. Nicht unterstützte Zeilen zu entfernen, nur um ein positives Prüfergebnis zu erzielen, würde den Abgleich zwecklos machen.

Das vollständige Prüfprogramm lokal ausführen

Speichern Sie Folgendes als check_invoice.py und starten Sie es mit python3 check_invoice.py. Es verwendet nur die Python-Standardbibliothek, benötigt keinen API Key und führt keine Netzwerkanfrage aus. Testdaten und Assertions gehören zum bereitgestellten Ergebnis: Leser können sowohl die versteckte Abweichung als auch den korrigierten Fall ohne kostenpflichtigen Modellaufruf reproduzieren.

"""Offline synthetic invoice check. No model/API request; USD integer cents only."""
import csv
import io
import json
import re

HEADER = ['line_id', 'description', 'qty', 'unit_usd', 'line_usd']
CSV = '''line_id,description,qty,unit_usd,line_usd
L1,Name badges,40,2.50,100.00
L2,Room signage,3,18.00,54.00
L3,Captioning service,2,45.00,80.00
'''

def cents(value):
    if not isinstance(value, str) or not re.fullmatch(r'[0-9]+\.[0-9]{2}', value):
        raise ValueError('Use unsigned USD amounts with exactly two decimals')
    whole, fraction = value.split('.')
    return int(whole) * 100 + int(fraction)

def check(text, invoice_total):
    reader = csv.reader(io.StringIO(text, newline=''), strict=True)
    if next(reader, None) != HEADER:
        raise ValueError('Unexpected CSV header')
    seen, rows, issues = set(), [], []
    for fields in reader:
        if len(fields) != len(HEADER):
            raise ValueError('Unexpected column count')
        ident, description, quantity, unit, quoted = fields
        if not ident or ident in seen or not description.strip():
            raise ValueError('Missing or duplicate line identity')
        if not re.fullmatch(r'[0-9]+', quantity) or int(quantity) < 1:
            raise ValueError('Quantity must be a positive whole number')
        seen.add(ident)
        expected, stated = int(quantity) * cents(unit), cents(quoted)
        rows.append(dict(line_id=ident, expected_cents=expected, stated_cents=stated))
        if expected != stated:
            issues.append(dict(line_id=ident, expected_cents=expected, stated_cents=stated))
    if not rows:
        raise ValueError('No invoice lines')
    declared = cents(invoice_total)
    expected_total = sum(x['expected_cents'] for x in rows)
    stated_sum = sum(x['stated_cents'] for x in rows)
    return dict(currency='USD', line_count=len(rows), line_issues=issues,
                expected_total_cents=expected_total, stated_line_sum_cents=stated_sum,
                declared_total_cents=declared, declared_matches_lines=declared == stated_sum,
                eligible_for_draft=not issues and declared == expected_total)

def draft_brief(report):
    if not report['eligible_for_draft']:
        raise ValueError('Resolve arithmetic before creating a drafting brief')
    return {k: report[k] for k in ['currency', 'line_count', 'expected_total_cents']}

def planned_microcredits(inputs, outputs, rate_in, rate_out):
    if any(type(x) is not int or x < 0 for x in [inputs, outputs, rate_in, rate_out]):
        raise ValueError('Planning quantities and rates must be nonnegative integers')
    numerator = inputs * rate_in + outputs * rate_out
    return (numerator + 999999) // 1000000

if __name__ == '__main__':
    bad = check(CSV, '234.00')
    assert bad['declared_matches_lines'] and not bad['eligible_for_draft']
    assert bad['expected_total_cents'] - bad['declared_total_cents'] == 1000
    try:
        draft_brief(bad)
    except ValueError:
        pass
    else:
        raise AssertionError('Bad invoice became a drafting brief')
    fixed = check(CSV.replace('45.00,80.00', '45.00,90.00'), '244.00')
    assert draft_brief(fixed) == dict(currency='USD', line_count=3, expected_total_cents=24400)
    rejected = 0
    for text, total in [
        (CSV.replace('L2,', 'L1,'), '234.00'),
        (CSV.replace(',40,', ',0,'), '234.00'),
        (CSV.replace(',40,', ',1e2,'), '234.00'),
        (CSV.replace('2.50', '2.500'), '234.00'),
        (CSV.replace('2.50', '-2.50'), '234.00'),
        (CSV.replace('L1,Name badges,', 'L1,Name badges,EXTRA,'), '234.00'),
        (CSV, '234,00'),
    ]:
        try:
            check(text, total)
        except ValueError:
            rejected += 1
        else:
            raise AssertionError('Invalid fixture accepted')
    rates = {'catalog_low': (18333360, 73333440), 'catalog_high': (36666720, 146666880)}
    plans = {key: planned_microcredits(1000, 300, *value) for key, value in rates.items()}
    assert plans == {'catalog_low': 40334, 'catalog_high': 80667}
    print(json.dumps(dict(bad=bad, corrected_brief=draft_brief(fixed),
                         negative_fixtures_rejected=rejected, planned_microcredits=plans), indent=2))

Das Skript liefert bei rechnerischen Abweichungen bewusst einen Bericht, löst bei fehlerhaften Eingaben aber einen Fehler aus. Das sind unterschiedliche Situationen: Eine verständliche Rechnung kann einen klärungsbedürftigen Widerspruch enthalten; formal ungültige Zeilen lassen sich unter dem festgelegten Vertrag dagegen nicht zuverlässig auslegen. Ein produktiver Import benötigt zusätzlich Größenlimits für Dateien, Zugriffskontrollen, Buchungskonventionen und eine zur Umgebung passende betriebliche Prüfung.

Den Bericht lesen, ohne eine Zahlungsentscheidung daraus zu machen

Das ausgeführte Ergebnis enthält declared_matches_lines: true und eligible_for_draft: false. Die erwartete Summe beträgt 24.400 Cent; sowohl ausgewiesene Gesamtsumme als auch Summe der angegebenen Positionen betragen 23.400 Cent. Die Abweichung nennt L3 mit angegebenen 8.000 Cent und erwarteten 9.000 Cent. Diese genauen Werte erklären, weshalb die oberflächlich passende Summe gesperrt wurde, statt nur eine allgemeine Warnung auszugeben.

Das Programm versuchte außerdem, aus dem fehlerhaften Bericht ein Briefing zu erzeugen, und bestätigte, dass die Funktion es verweigert. Für den ausdrücklich korrigierten Testdatensatz gab es {"currency":"USD","line_count":3,"expected_total_cents":24400} zurück. Dieses kompakte Objekt ist die erfolgreiche lokale Übergabe. Es ist weder eine Modellantwort noch ein Nachweis steuerlicher Konformität oder eine Freigabe zur Zahlung von USD 244.00.

Abbildung: Ergebnisse des lokalen Python-Tests, keine Ausgabe eines DeepSeek-Modells.

Sieben Negativfälle wurden tatsächlich abgelehnt: doppelte Kennung, Menge null, Menge in Exponentenschreibweise, zu viele Nachkommastellen beim Betrag, negativer Einzelpreis, zusätzliche Spalte und Gesamtsumme mit Dezimalkomma. Das prüft gezielt den Beispielvertrag, beweist aber nicht die Sicherheit jedes Lieferantenexports. Auch CSV-Syntaxfehler können das Einlesen stoppen; das Skript verspricht keine automatische Wiederherstellung beliebig beschädigter Dateien.

DeepSeek eine geklärte Aufgabe und klare Grenzen geben

Nach Klärung durch den Lieferanten oder die zuständige prüfende Person kann die Koordination DeepSeek um eine neutrale Empfangsbestätigung bitten, ausschließlich mit genehmigten Fakten. Eine vorgeschlagene Anfrage wäre: „Formuliere eine kurze Bestätigung, dass uns die korrigierte USD-Rechnung mit drei Positionen und abgeglichener Summe von 244.00 vorliegt. Behaupte nicht, dass eine Zahlung genehmigt oder terminiert ist. Bitte die prüfende Person, vor dem Versand die Referenznummer zu bestätigen.“ Diese Anfrage wurde hier nicht ausgeführt.

Das aktuelle Orux-Modellformular stellt messages, max_tokens und eine JSON-Objekt-Antwortoption für deepseek-v4.1-flash bereit. Damit sind die verfügbaren Einstellungen bestätigt, keine erfolgreiche Ausführung dieser Rechnungstext-Aufgabe. Verwenden Sie den genauen Orux-Alias der Modellseite. Der Modellname auf DeepSeeks eigenem Dienst ist eine andere Dienstkennung und darf nicht als vermeintlicher Orux-Alias übernommen werden.

Die DeepSeek-Referenz zu Chat Completions dokumentiert Verbrauchsangaben. Bei einem tatsächlich ausgeführten Aufruf zählen die zurückgegebenen Verbrauchsdaten; weder CSV-Zeichen noch die Zahl der Rechnungspositionen bestimmen die Tokenmenge. Wenn ein JSON-Objekt zurückkommen soll, validieren Sie anschließend dessen Felder und Werte. Eine Formularoption oder eine höflich wirkende Antwort ersetzt diese Prüfung nicht.

Als Ergänzung untersucht der Museumsfall mit JSON (auf Englisch) die Ausgabevalidierung; der Support-Digest-Leitfaden (auf Englisch) bereitet eine andere Art begrenzter Eingabe vor. Dieser Rechnungsablauf ergänzt den rechnerischen Abgleich, statt deren Extraktions- oder Datenschutzprüfungen zu wiederholen.

Die zwei veröffentlichten Orux-Tarifzeilen vergleichen

Der öffentliche Katalog enthält am 2. November 2026 zwei dailytimeband-Zeilen für diesen Alias. Die Tabelle nutzt ausschließlich Eingabe- und Ausgabetarife ohne Cache. Sie setzt weder voraus, dass wiederholte Rechnungen einen Cachetarif erhalten, noch leitet sie das für ein Konto geltende Zeitband aus der Uhrzeit ab. Bestätigen Sie das aktuelle Angebot und seine Bedingungen, bevor Sie einen Aufruf autorisieren. Die Tabelle übernimmt den Dezimalpunkt des Katalogs.

Horizontal wischen, um die ganze Tabelle zu sehen.

Die letzte Spalte ist eine Planungsrechnung, kein gemessener Verbrauch und keine zugesicherte Rechnung. Das Programm rundet jeden geplanten Aufruf auf den nächsten ganzen micro-Credit auf. Tausend Aufrufe mit exakt diesen geplanten Mengen ergeben unter dieser Konvention daher ein Budget von 40,334 oder 80,667 Credits. Tatsächlicher Verbrauch, Bedingungen und weitere Versuche verändern das Ergebnis. Für diesen Artikel wurde keine Kontobelastung gemessen.

Die Preisseite des Herstellers beschreibt dessen eigene Modellversionen und Zeitpläne. Daraus folgen weder Orux-Zeitpläne noch ein Kontoangebot. Wir behaupten weder eine bessere Rechnungsgenauigkeit gegenüber einem anderen Modell noch niedrigere Kosten eines Dienstes unter allen Bedingungen. Der Rechner macht einen ausdrücklichen Plan vor einer optionalen Anfrage überprüfbar.

Abgleich, Formulierung und Freigabe getrennt dokumentieren

Bewahren Sie Original-CSV, ausgewiesene Summe, Abweichungsbericht und genehmigte Korrektur auf. Prüfen Sie die korrigierten Daten erneut und dokumentieren Sie danach das genaue Briefing für den optionalen Modellschritt. So bleiben Lieferantenangaben, Programmrechnung und menschliche Freigabe unterscheidbar. Eine generierte Bestätigung darf keine dieser Aufzeichnungen überschreiben.

Ergänzt der Textschritt ein nicht autorisiertes Zahlungsdatum, Bankdaten, eine Referenznummer oder Freigabe, weisen Sie diese Ergänzung zurück und klären sie mit der zuständigen Person. Dieser Leitfaden zeigt kein generiertes Beispiel und behauptet nicht, ein bestimmter Prompt verhindere solche Ergänzungen. Sein fertiger Beitrag ist die lokale Rechensperre mit reproduzierbarem Nachweis, bereit für einen separat geprüften Kommunikationsschritt.

Preise und Formular geprüft am 2026-11-02. Quellen: Orux-Modell, öffentlicher Katalog, Python CSV, numerische Python-Typen, DeepSeek-Referenz, DeepSeek-Preise.

FAQ

Q.Beweist eine passende Rechnungssumme die Richtigkeit jeder Position?

Nein. Die gezeigte Summe stimmt mit den angegebenen Positionen überein, obwohl L3 die Regel Menge mal Einzelpreis verletzt. Vergleichen Sie unabhängig berechnete Positionsbeträge und Gesamtsumme. Das Programm benennt diesen genauen Widerspruch; ein Mensch muss anschließend bestimmen, welcher Quellwert korrigiert werden soll.

Q.Hat DeepSeek die Abweichung von USD 10 gefunden?

Nein. Das lokale Python-Programm hat sie gefunden; kein Modell wurde aufgerufen. DeepSeek ist ein optionaler späterer Formulierungsschritt mit geprüften aktuellen Orux-Einstellungen und datierten Planungstarifen. Der Artikel bewertet weder Rechnungsgenauigkeit noch Qualität, Latenz oder Zuverlässigkeit des Modells.

Q.Eignet sich das für Steuern oder mehrere Währungen?

Nicht unter dem aktuellen Vertrag. Er umfasst positive ganze Mengen und vorzeichenlose USD-Beträge mit zwei Nachkommastellen, ohne Regeln für Steuern, Rabatte oder Währungsumrechnung. Erweitern und testen Sie diese Regeln ausdrücklich anhand der genehmigten Buchungsspezifikation, statt unpassende Zeilen zu löschen oder Gebietskonventionen zu erraten.

Q.Sind die Credits der Preis für die Prüfung dieser CSV?

Nein. Der lokale Prüfer sendet keine Orux-Anfrage und verbraucht keine Website-Credits. Die Tabelle schätzt einen optionalen späteren Aufruf mit angenommenen Tokenmengen. Dessen tatsächlicher Verbrauch und das geltende aktuelle Angebot bestimmen die Kosten, nicht die CSV-Zeilenzahl.

Q.Was ist vor dem Versand einer generierten Bestätigung zu prüfen?

Vergleichen Sie sie mit der genehmigten Korrektur und der tatsächlich erteilten Kommunikationsbefugnis. Eine abgeglichene Summe erlaubt weder Zahlung noch Zahlungsdatum. Bewahren Sie den Quellbericht getrennt auf, verwerfen Sie unbelegte Angaben und bestätigen Sie Referenznummer und Empfänger, bevor Sie eine Nachricht senden.