Communitygithub.com

pay-invoices-safely

Rechnungen sicher bezahlen: Führen Sie vor der Zahlung einer Lieferantenrechnung oder der Änderung von Bankdaten die integrierten Prüfungen von Jithox durch, um Betrug zu vermeiden.

Was ist pay-invoices-safely?

Diese Fähigkeit (Skill) ermöglicht es KI-Agenten, Lieferantenrechnungen sicher zu bezahlen, indem sie vor der Freigabe einer Zahlung oder der Änderung von Bankdaten strukturierte Prüfungen durchführt. Sie ist ideal für Szenarien wie neue IBANs in E-Mails, abweichende Kontodaten auf Rechnungen oder die Vorbereitung von Zahlungsläufen. Der Skill unterstützt mehrere Plattformen (MCP, Plain HTTP) und bietet sowohl kostenlose (IBAN-Validierung, Rechnungsprüfung nach Peppol BIS Billing 3.0) als auch kostenpflichtige Prüfungen (EU VIES Umsatzsteuer-ID-Prüfung). Der Workflow ist zweistufig: zuerst die kostenlose Prüfung (`check_payment_change` und `POST /api/invoice/review`), dann optional die kostenpflichtige `review_invoice` für die Umsatzsteuer-Prüfung. Der Agent bereitet die Prüfung vor und dokumentiert alle Ergebnisse; die finale Zahlung wird jedoch immer von einer Person freigegeben. Der Skill erkennt verdächtige Kontowechsel, ungültige IBANs und fehlerhafte Rechnungen und gibt klare Handlungsanweisungen (z. B. „Rückruf erforderlich“), sodass Zahlungen bei Betrugsverdacht zurückgehalten werden können.

Funktioniert mit~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/victor-emmanuel-c/jithox-mcp/tree/main/skills/pay-invoices-safely

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

Dokumentation

Rechnungen sicher bezahlen

Sie sind im Begriff, eine Lieferantenrechnung zu bezahlen oder die Bankverbindung eines Lieferanten zu ändern. Bevor Geld bewegt wird, führen Sie die unten stehenden Prüfungen durch und übergeben Sie der Person, die die Zahlung freigibt, die Ergebnisse.

Verwenden Sie diesen Skill, wenn:

  • ein Lieferant (oder jemand, der vorgibt, der Lieferant zu sein) neue Bankdaten sendet;
  • die IBAN auf einer Rechnung von der im Lieferantenstamm hinterlegten Kontoverbindung abweicht;
  • Sie einen Zahlungslauf vorbereiten und jede Rechnung vorher prüfen möchten;
  • Sie gefragt werden: „Ist diese Rechnung zahlbar?“.

Die beiden kostenlosen Prüfungen benötigen weder ein Konto noch einen Token.

Verbinden

MCP-Server (Streamable HTTP, JSON-RPC 2.0):

{
  "mcpServers": {
    "jithox": { "url": "https://jithox.com/api/mcp" }
  }
}

Einfaches HTTP funktioniert ebenfalls; jedes unten stehende Beispiel ist ein curl-Aufruf. Setzen Sie Ihren eigenen User-Agent wie gezeigt, damit diese Aufrufe von anderem Datenverkehr unterschieden werden können.

Schritt 1 – Neue oder geänderte Bankverbindung: check_payment_change

Rufen Sie dies auf, wenn ein Lieferant ein neues Konto angibt und wenn die IBAN auf der Rechnung nicht mit der hinterlegten übereinstimmt (dann ist die IBAN der Rechnung die neue). Lassen Sie ibanOnFile bei der ersten Zahlung an einen neuen Lieferanten weg; die Antwort teilt dann mit, dass kein Vergleich möglich war.

curl -s https://jithox.com/api/mcp \
  -A 'pay-invoices-safely/1.0' \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"check_payment_change","arguments":{"newIban":"DK27 5301 0244 5638 21","ibanOnFile":"DK50 0040 0440 1162 43","supplierCountry":"DK"}}}'

Das Ergebnis des Tools (result.content[0].text), ausgeführt gegen die Produktion am 24.09.2026 und gekürzt, wo … steht:

{
  "kind": "payment_change_check",
  "data": {
    "verdict": "verify_first",
    "summary": "Die neue Nummer ist ein wohlgeformtes Konto, und nichts daran ist auffällig. Es handelt sich dennoch um eine Änderung des Zahlungsziels: Bestätigen Sie es telefonisch, bevor Sie den Datensatz aktualisieren.",
    "newAccount": { "status": "valid", "iban": "DK27 5301 0244 5638 21", "country": "Denmark", … },
    "accountOnFile": { "status": "valid", "iban": "DK50 0040 0440 1162 43", "country": "Denmark", … },
    "flags": [
      { "code": "bank_changed", "severity": "note", "what": "Gleiches Land, andere Bank (Kennung 0040 → 5301). An sich normal – Unternehmen wechseln durchaus Banken –, aber im Rückruf erwähnenswert." }
    ],
    "requiredSteps": [
      "Rufen Sie den Lieferanten unter einer Telefonnummer aus IHREN eigenen Unterlagen oder einer früheren, bezahlten Rechnung an – niemals aus der Änderungsanfrage oder deren E-Mail-Signatur.",
      "Lassen Sie sich die neue Kontonummer vorlesen; lesen Sie sie nicht vor.",
      "Lassen Sie eine zweite Person die Änderung im Lieferantenstamm freigeben, bevor Zahlungen ausgeführt werden.",
      "Bewahren Sie die Anfrage, den Namen der Person, mit der Sie gesprochen haben, und den Zeitpunkt des Anrufs zusammen mit dem Lieferantendatensatz auf."
    ],
    "doesNotProve": "Wem das neue Konto gehört, ob es existiert oder aktiv ist oder ob die Anfrage tatsächlich vom Lieferanten stammt. Kein kostenloses Register beantwortet diese Fragen. Nur der Rückruf tut das.",
    …
  }
}

Handeln Sie basierend auf verdict:

verdictWas Sie tun
no_changeGleiches Konto, anders geschrieben. Fahren Sie mit Schritt 2 fort. Wenn die Anfrage behauptete, die Daten seien neu, rechtfertigt die Diskrepanz einen Rückruf.
verify_firstNicht bezahlen und den Lieferantendatensatz nicht ändern. Übergeben Sie die requiredSteps an eine Person.
stopAuffälligkeiten. Nicht bezahlen, andere Zahlungen an diesen Lieferanten zurückhalten, flags und requiredSteps an eine Person übergeben.
invalid_new_accountDie Nummer kann keine IBAN sein. Nicht bezahlen. Fordern Sie die Nummer über einen bereits bekannten Kommunikationsweg vom Lieferanten an.
Keine Antwort (Timeout, HTTP-Fehler oder Tool-Fehler)Kein Bestehen. Nicht bezahlen oder den Lieferantendatensatz ändern; an eine Person übergeben.

Der Rückruf ist die eigentliche Prüfung. Eine Person ruft den Lieferanten unter einer Telefonnummer an, die NICHT aus der E-Mail, der Änderungsanfrage oder der Rechnung stammt. Sie können diesen Anruf nicht für sie tätigen, und eine wohlgeformte IBAN ist keine sichere IBAN.

Der gleiche Aufruf für die Fälle stop, no_change und invalid_new_account befindet sich in references/examples.md.

Schritt 2 – Die Rechnung selbst: POST /api/invoice/review (kostenlos)

Senden Sie die Rechnung als strukturierte Daten. Die Prüfung überprüft die Struktur, berechnet die Summen neu, prüft die IBAN auf der Rechnung und wendet die Peppol BIS Billing 3.0-Regeln an. Kein Konto, kein Token, keine Kosten. Wie review_invoice verarbeitet sie strukturierte Daten, kein PDF oder Scan: Wandeln Sie diese zuerst in Felder um.

curl -s https://jithox.com/api/invoice/review \
  -A 'pay-invoices-safely/1.0' \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json' \
  -d '{"invoice":{"invoiceNumber":"2026-0917","issueDate":"2026-09-17","dueDate":"2026-10-17","currency":"DKK","buyerReference":"PO-4471","supplier":{"name":"Nordlys Tryk ApS","countryCode":"DK","vatId":"DK31500060","endpointId":"5790000000012","endpointScheme":"0088"},"customer":{"name":"Havn Logistik A/S","countryCode":"DK","vatId":"DK31500044","endpointId":"5790000000029","endpointScheme":"0088"},"lines":[{"description":"Printing, September","quantity":1,"unitPrice":8000,"vatPercent":25}],"totalWithoutVat":8000,"totalVat":2000,"totalWithVat":10000,"payment":{"iban":"DK27 5301 0244 5638 21"}}}'

Ausgeführt gegen die Produktion am 24.09.2026, gekürzt:

{
  "review": {
    "checks": [
      { "id": "structure", "status": "pass", … },
      { "id": "arithmetic", "status": "pass", "detail": "Zeilen- und Mehrwertsteuersummen stimmen mit den Rechnungsbeträgen überein.", … },
      { "id": "payment_details", "status": "pass", "detail": "DK27 5301 0244 5638 21 ist eine strukturell gültige dänische IBAN. Dies sagt nicht aus, ob das Konto existiert oder wem es gehört.", … },
      { "id": "supplier_vat", "status": "skipped", "detail": „Das VIES-Register wurde nicht abgefragt: Dieser Durchlauf hatte keinen autorisierten Workspace dafür.“, … },
      { "id": "customer_vat", "status": "skipped", … },
      { "id": "peppol", "status": "pass", … }
    ],
    "findings": [],
    "readyToSend": true,
    "hasUnknowns": true,
    …
  },
  "verified": false,
  "billing": { "charged": false, "reason": "Abgemeldet: Es liefen nur die kostenlosen lokalen Prüfungen, es wurde nichts berechnet.", … }
}

Wie ist es zu lesen:

  • Ohne Konto werden die beiden Umsatzsteuer-Prüfungen als skipped geführt: Das VIES-Register wurde nicht befragt. Deshalb ist hasUnknowns true. Teilen Sie dies der Person mit; melden Sie die Umsatzsteuer-IDs niemals als geprüft.
  • Jeder Eintrag in findings hat eine severity und einen fix. Ein blocker bedeutet, dass die Rechnung falsch ist (z. B. eine Summe, die nicht stimmt): Bezahlen Sie sie nicht, fordern Sie eine korrigierte Rechnung vom Lieferanten an. Ein Beispiel befindet sich in references/examples.md.
  • payment_details sagt nur aus, dass die IBAN wohlgeformt ist. Ob es sich um das Konto des Lieferanten handelt, ist Schritt 1, nicht diese Prüfung.

Schritt 3 – Umsatzsteuer-IDs aus dem EU-Register: review_invoice (kostenpflichtig)

Führen Sie dies erst nach Schritt 2 durch. Es wiederholt die strukturierten Rechnungsprüfungen und fügt Prüfungen der Lieferanten- und Kunden-Umsatzsteuer-IDs gegen das EU-VIES-Register hinzu. Das Live-Eingabeschema liest die Zahlungsdaten und die erklärten Rechnungssummen. Es wird ein Token benötigt:

  1. Eine Person (nicht der Agent) erstellt eine Jithox-Verbindung unter https://jithox.com/mcp/account#connection.
  2. Der Agent tauscht die Verbindungs-ID und das Secret gegen einen Token unter /api/oauth/token ein:
curl -s https://jithox.com/api/oauth/token \
  -A 'pay-invoices-safely/1.0' \
  -H 'Accept: application/json' \
  -d grant_type=client_credentials \
  -d "client_id=$JITHOX_CLIENT_ID" \
  -d "client_secret=$JITHOX_CLIENT_SECRET"

Setzen Sie den Access-Token aus der Antwort in JITHOX_TOKEN. Ein abgelaufener oder abgelehnter Token liefert die gleiche payment_required-Antwort wie kein Token. Holen Sie einen neuen Token und versuchen Sie es einmal erneut.

  1. Rufen Sie das Tool mit dem Token auf (die Rechnungsfelder gehen direkt in arguments):
curl -s https://jithox.com/api/mcp \
  -A 'pay-invoices-safely/1.0' \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -H "Authorization: Bearer $JITHOX_TOKEN" \
  -d '{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"review_invoice","arguments":{"invoiceNumber":"2026-0917","issueDate":"2026-09-17","dueDate":"2026-10-17","currency":"DKK","buyerReference":"PO-4471","supplier":{"name":"Nordlys Tryk ApS","countryCode":"DK","vatId":"DK31500060","endpointId":"5790000000012","endpointScheme":"0088"},"customer":{"name":"Havn Logistik A/S","countryCode":"DK","vatId":"DK31500044","endpointId":"5790000000029","endpointScheme":"0088"},"lines":[{"description":"Printing, September","quantity":1,"unitPrice":8000,"vatPercent":25}],"totalWithoutVat":8000,"totalVat":2000,"totalWithVat":10000,"payment":{"iban":"DK27 5301 0244 5638 21"}}}}'

Der Preis befindet sich nicht in dieser Datei, da sich Preise ändern: Lesen Sie das Feld pricing von review_invoice unter https://jithox.com/mcp.json. Ohne Token antwortet das Tool mit payment_required, führt keine Prüfungen durch und nennt humanUrl und tokenUrl.

Mit Token, ausgeführt gegen die Produktion am 24.09.2026, gekürzt:

{
  "kind": "invoice_review",
  "data": {
    "checks": [
      …
      { "id": "supplier_vat", "status": "unknown", "source": "eu_vies", "detail": "Das VIES-Register hat nicht geantwortet." },
      { "id": "customer_vat", "status": "fail", "source": "eu_vies", "detail": "VIES meldet diese Nummer als nicht registriert." },
      …
    ],
    "findings": [
      { "code": "supplier_vat_unverified", "severity": "warning", "what": "Wir konnten kein Urteil über die Umsatzsteuer-ID DK31500060 fällen. Das VIES-Register hat nicht geantwortet.", "fix": "Später erneut prüfen. Behandeln Sie dies als ungeprüft – es ist weder ein Beleg dafür, dass die Nummer gültig noch ungültig ist." },
      { "code": "customer_vat_not_registered", "severity": "blocker", "what": "VIES kennt die Umsatzsteuer-ID DK31500044 nicht.", "fix": "Überprüfen Sie die Nummer mit dem Kunden – ein Tippfehler, eine abgemeldete Registrierung oder eine Nicht-EU-Nummer würden alle so aussehen." }
    ],
    "readyToSend": false,
    "hasUnknowns": true,
    …
  }
}

unknown ist kein Bestehen: Das Register hat nicht geantwortet, also ist die Nummer ungeprüft. Ein fail bei der Umsatzsteuer-ID des Lieferanten ist ein Grund, die Zahlung zurückzuhalten und nachzufragen. Die Umsatzsteuer-IDs in diesen Beispielen sind erfunden, daher kennt das Register sie nicht.

Schritt 4 – Entscheiden und mitteilen, was nicht geprüft wurde

Jithox bezahlt niemals und unterschreibt niemals eine Zahlung, und keiner dieser Aufrufe erfordert ein Bank-Login oder einen Signaturschlüssel. Sie bereiten vor; eine Person genehmigt die Zahlung.

Halten Sie die Zahlung zurück und übergeben Sie sie an eine Person, wenn einer dieser Punkte zutrifft:

  • Schritt 1 ergab ein verdict anders als no_change;
  • Schritt 2 hat keine Antwort zurückgegeben, die keinen blieger-Befund enthält;
  • Schritt 3 enthält einen Befund mit der severity blocker;
  • eine benötigte Umsatzsteuer-Prüfung ist skipped, unknown oder fail;
  • eine Prüfung ergab keine Antwort: ein Timeout, ein HTTP-Fehler, ein JSON-RPC-Fehler oder ein Tool-Fehler ist kein Bestehen. Nicht bezahlen; an eine Person übergeben.

Selbst wenn alles bestanden wird, ist eine saubere Antwort keine Garantie. Fügen Sie den doesNotProve-Text aus Schritt 1 und das detail jeder Prüfung, die nicht pass ist, Wort für Wort in Ihre Notiz ein. Eine kurze Notiz:

Rechnung 2026-0917 von Nordlys Tryk ApS, DKK 10000,00 an DK27 5301 0244 5638 21.
Bankverbindung: verify_first (Bank gewechselt 0040 -> 5301). NICHT bezahlt.
  Rufen Sie den Lieferanten unter der Nummer aus unseren eigenen Unterlagen an; lassen Sie sich das Konto vorlesen.
  Nicht belegt: wem das neue Konto gehört, dass es existiert oder aktiv ist, oder dass die Anfrage vom Lieferanten stammt.
Rechnung: Struktur, Summen, IBAN-Format und Peppol-Regeln bestanden.
USt.-ID: nicht geprüft (übersprungen, kein Konto).
Erfordert: Rückruf + zweite Freigabe vor Zahlung.

Verwandte Skills