Zahlungsabgleich und PSP-Berichte

TL; DR

Der Abgleich ist die tägliche automatisierte Vernetzung Ihres Ledgers und Events (auth/capture/refund/payout) mit PSP/Acquirer/Bank Reports. Der Schlüssel zum Erfolg: ein einheitliches Datenmodell, deterministische Matching-Schlüssel, strikte Idempotenz, Toleranzen nach Betrag/FX/Zeit, DLQ-Warteschlange für umstrittene Fälle und Autokorrektur-Playbooks. KPI: Recon Mismatch Rate↓, Aging of Unreconciled↓, Auto-match%↑.

1) Warum und was wir überprüfen

Ziele: Nachweis von Einnahmen und Provisionen, Erkennung von Takes/Loss, korrekte Einstellung nach Tagen und Währungen, Kontrolle von Refund-to-Source, Einhaltung von Audit/Regulator.

• Deposits: `auth → capture → settle`
• Refunds: Voll-/Teilbetrag, Status und Beträge
• Payouts/Withdrawals: Ausgehende Zahlungen nach Methode
• Fees & Adjustments: PSP-Provisionen, Interbankenregelungen, Korrekturen
• Chargebacks/Disputes: Außerhalb Ihrer Initiative
• FX/Umrechnungen: Kurse, Spreads, Fixing Moment

2) Datenquellen

Interne Veranstaltungen (Ihre): Event-Bus/Kafka, 'payments _ flat', 'refunds', 'payouts', Ihr Ledger.

• Transaktionen (Betriebsauszüge)
• Settlements/Batches (Aufschlüsselungen der T + N-Einschreibungen)
• Fees/Statements (Provisionen, Anpassungen)
• Chargebacks/Disputes
• Zahlungsmittel/ÜLG/RTP/SEPA-Register
• Bank Statements: MT940/CSV/ISO20022 CAMT, Pull-up-Einschreibungen.

3) Übereinstimmende Schlüssel (Matching Keys)

1. provider_txid ↔ provider_txid (eindeutige PSP-ID)

2. idempotency_key/ merchant_reference (wenn PSP stabil ist)

3. (amount, currency, timestamp_bucket, last4/bin, auth_code)

4. Fuzzy-Schicht: ± Toleranzen in Summe/Zeit, BIN/issuer Land, Status Familie

• Behalten Sie beide: 'payment _ id' und 'provider _ txid'.
• Für partial/refund: 'sequence _ index' oder 'refund _ line _ id' hinzufügen.
• Для payouts — `payout_batch_id + line_id`.
• Für FX ist 'exec _ id' (Konvertierung) und die Quelle des Kurses.

4) Datenmodell (normalisierte Schicht)

json
{
"source": "INTERNAL    PSP_TX    PSP_SETTLEMENT    BANK",
"provider": "Acquirer_A",
"payment_id": "pay_123",
"provider_txid": "psp_tx_789",
"kind": "AUTH    CAPTURE    REFUND    PAYOUT    FEE    SETTLEMENT    CHARGEBACK",
"sequence": 0,
"amount": 100. 00,
"currency": "EUR",
"fee_amount": 1. 20,
"fx_rate": 1. 0000,
"fx_src": "PSP    ECB    BANK",
"status": "APPROVED    CAPTURED    SUCCESS    FAILED    SETTLED",
"event_ts": "2025-11-03T12:00:00Z",
"settlement_date": "2025-11-05",
"account": "PSP_MERCHANT_CARD_A",
"matching_keys": {
"provider_txid": "psp_tx_789",
"merchant_ref": "mr_456",
"idem_key": "idem_abc"
},
"hash_row": "sha256(...)"
}

5) Abstimmungsprozess (ETL/Orchestrierung)

1. Ingest: Wir nehmen PSP-Berichte (SFTP/API), validieren das Schema/die Signaturen und speichern sie in 'raw'.
2. Normalize: Mappim Felder in ein einheitliches Format (currency ISO, decimals, timzone UTC).
3. Match: Schlüsselbaum-Matching-Algorithmus mit Toleranzen.
4. Post-Match: Wir bilden diff (Diskrepanzen) und Journaleinträge für Ledger/Korrekturen.
5. Settle: Nähen Sie' PSP _ SETTLEMENT ↔ BANK'(Gutschriften auf dem Konto), streuen Sie nach Tag/Schlacht.
6. Bericht: Dashboard, Alerts; umstritten in DLQ für manuelle Analyse/Auto-Neuausrichtung.

Idempotenz: für jede Datei/Seite - 'ingest _ id'. Das erneute Laden ändert das Ergebnis nicht.

6) Toleranzen und Regeln

Zeit: '± 15 min' für Transaktionen, '± 1 Tage' für settlement.
Betrag: '≤ 0. 01 'Basiswährung oder' ≤ 10 bps' für FX/fee-Differenzen.
FX: Wir erlauben eine Diskrepanz mit der Bank, wenn die Quelle des Kurses unterschiedlich ist; „fx _ src“ wird festgelegt.
Partial/Multiple: Der Betrag auf den Linien partial/refund muss dem internen Saldo entsprechen.

7) Umgang mit Diskrepanzen (diff taxonomy)

8) Ledger & Buchhaltung (Buchungen)

Capture: `DR Accounts Receivable / CR Revenue` и `DR Cash (upon settle) / CR Accounts Receivable`

Fee: `DR Fees / CR Cash or Payable`

Refund: Rückbuchungen anteilig partiell

Chargeback: Einzelkonten und Rückstellung für Streitigkeiten

FX reval: Tägliche Neubewertung des AR-/Cache-Restwerts zum Kurs' fx _ src _ policy '

9) KPIs und Ziele

Auto-Match% = automatisch zugeordnete Zeilen/alle Zeilen (Ziel ≥ 95%)

Recon Mismatch Rate = diff-Zeilen/alle Zeilen (≤ 1-2%)

Aging of Unreconciled: p50/p95 Tage im DLQ (p95 ≤ 3 Tage)

Settlement Timeliness: Anteil der Gefechte, die mit der D-Day-Bank genäht wurden (≥ 99%)

Fee Accuracy: Diskrepanz zwischen Provisionen und Providern (≤ 0. 1% des Umsatzes)

Duplicate/Orphan Incidents: Tendenziell 0

10) SQL-Schnitte

10. 1 Grundlegender Vergleich nach provider_txid

sql
WITH i AS (
SELECT provider, provider_txid, kind, amount, currency, event_ts
FROM internal_norm
),
p AS (
SELECT provider, provider_txid, kind, amount, currency, event_ts
FROM psp_norm
)
SELECT
COALESCE(i. provider_txid, p. provider_txid) AS txid,
COALESCE(i. provider, p. provider) AS provider,
i.kind AS kind_internal, p. kind AS kind_psp,
i.amount AS amount_internal, p. amount AS amount_psp,
i.currency, p. currency,
CASE
WHEN i.provider_txid IS NULL THEN 'MISSING_INTERNAL'
WHEN p. provider_txid IS NULL THEN 'MISSING_PSP'
WHEN ABS(i. amount - p. amount) > 0. 01 THEN 'AMOUNT_MISMATCH'
ELSE 'MATCHED'
END AS recon_status
FROM i
FULL OUTER JOIN p USING (provider, provider_txid);

10. 2 Settlement ↔ Bank

sql
SELECT s. settlement_date, s. batch_id, s. currency,
s. amount_settled, b. amount_bank,
(b. amount_bank - s. amount_settled) AS diff
FROM psp_settlements s
LEFT JOIN bank_statements b
ON b. value_date = s. settlement_date
AND b. currency = s. currency
AND ABS(b. amount_bank - s. amount_settled) <= 0. 5;

10. 3 Aging DLQ

sql
SELECT diff_type,
COUNT() AS cnt,
PERCENTILE_CONT(0. 5) WITHIN GROUP (ORDER BY AGE(NOW(), created_at)) AS p50_age,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY AGE(NOW(), created_at)) AS p95_age
FROM recon_dlq
GROUP BY diff_type
ORDER BY cnt DESC;

11) Eigenschaften auf Schienen/Fällen

Karten: Unterschiede zwischen 'auth' und 'capture', späte' settlement 'Anpassungen, Interchange/Schema fee - getrennte Linien.
A2A/Open Banking/RTP: sofortige Bestätigungen, aber „reversal“ möglich; überprüfen Sie' Auszahlung 'und Rückerstattungen.
Geldbörsen: oft ideal 'provider _ txid', schnell 'refund'; folgen Sie den fee-Linien.
Gutscheine: kein symmetrischer Refund - korrekt in Politik und Berichten spiegeln.
Krypto: On-Chain-Hash ↔ provider_txid; Konfirmanden N; Berücksichtigung der Netzprovisionen und möglicher Rebuys; Kurs - zum Zeitpunkt der Umwandlung.

12) Operative Playbooks

Splash MISSING_INTERNAL: Überprüfen Sie den Verlust von Webhooks/Retrays, spielen Sie ingestion erneut, aktivieren Sie die Polling-API.
AMOUNT_MISMATCH bei einem PSP: Rundungen/MwSt./Gebührenmodell vergleichen, Korrekturklausel anfordern.
Settlement näht nicht mit der Bank: Überprüfen Sie das Wertdatum, die Bankgebühren, die T + N-Verzögerungen; vorübergehend auf „Suspense Account“ setzen.
Massive REFUND_OVER: sofortiger Stopp von Auto-Refands, Idempotenz-Audit, manuelle Korrektur.
FX_DRIFT: Fixieren Sie die Politik der Kursquelle (EZB/PSP/BANK) und berechnen Sie die P & L-Differenzen neu.

13) Kontrolle und Sicherheit

Idempotenz von ingestion: 'file _ id + checksum' und Download-Log.
Zugriffe (RBAC) und 4-Augen-Steuerung: auf manuelle Korrekturen/Logbuchungen.
Audit-Trail: Alle Matches/Difs/Korrekturen stehen in einem unveränderlichen Logbuch.
Datenqualität: Schemata, Pflichtfelder, Währungs-/Skale-Validierung.

14) Dashboard und Alerts

Widgets: Auto-Match%, Mismatch Rate, Aging DLQ, Settlement Timeliness, Fee Accuracy, Top PSP von Diffs, Diff-Typ Karte.

• 'Auto-Match% <90%' nach Anbieter/Tag → P1
• ` Aging p95> 3 dn ` → P2
• `AMOUNT_MISMATCH spike` → P1
• „Bank≠Settlement“ nach Betrag/Währung → P0

15) Testfälle (UAT/Prod)

1. Das erneute Herunterladen derselben Datei → 0 Nebenwirkungen (Idempotenz).
2. Teilrefands (3 Linien) → die Summe stimmt überein, das Match ist sequence.
3. FX-Konvertierung: Abweichung des Kurses innerhalb der Toleranzgrenzen → korrektes Match.
4. Duplikate provider_txid im Bericht → dedup und alert.
5. Der fehlende Webhook Capture → Polling hat die Lücke geschlossen, der Status ist ausgeglichen.
6. Settlement-Batch mit Fee-Line → korrekte Aufteilung auf Revenue/Fee/Net.

16) Häufige Fehler und wie zu vermeiden

Compare' attempt 'vs' capture') → Halten Sie die gleiche Granularität.
Das Fehlen von 'provider _ txid' im → geht an Genauigkeit verloren.
Ignorieren Sie Zeitzonen → Verschiebungen nach settlement-Daten.
Keine DLQ/Retrays → „ewige“ Diskrepanzen.
Manuelle Bearbeitungen ohne Logbuch → Unpassbarkeit mit Audit.
Fuzzy-Toleranzen → entweder ein Re-Match oder „alles in DLQ“.

17) Checkliste zur Umsetzung

• Einheitliches Normalisierungsschema und PSP/Methoden-/Kontoverzeichnisse
• Zuordnungsschlüsselbaum (txid → merchant_ref → fuzzy)
• Gesamt-/Zeit-/FX-Toleranzen, Kursquellenrichtlinie
• Idempotente Ingestion, DLQ, Retrais, Alerts
• Abgleich Settlement↔Bank, Suspense Account Politik
• KPI Dashboard, Reporting für Finanzen/Wirtschaftsprüfung
• Playbooks und SLAs zur Analyse von Diff-Fällen

Zusammenfassung

Überleitung ist eine Ingenieurdisziplin: Normalisierung, zuverlässige Schlüssel, Toleranzen, automatische Matches und transparente Korrekturen. Mit dieser Kontur stabilisieren Sie Einnahmen und Provisionen, minimieren schwarze Löcher, beschleunigen den Periodenschluss und werden schmerzfrei auditiert: Auto- match%↑, Mismatch↓, Aging↓.