📘

Zahlungen & Banking

payments sales_billing 🛡️ RLS Protected

Zahlungen & Banking — aus Code abgeleitete Prozess- und API-Dokumentation.

Fachliche Bestimmung: Rechnungen & Finanzbuchhaltung steuert die kaufmännische Gesamtabrechnung und das Rechnungswesen: Erzeugung gesetzskonformer E-Rechnungen (ZUGFeRD 2.2 / XRechnung nach EN 16931), Festschreibung nach GoBD, Laufende Debitoren- und Kreditorenverwaltung mit automatisiertem Bankabgleich (CAMT.053), mehrstufiges Mahnwesen, revisionssichere Hauptbuchführung nach SKR03/SKR04 und DATEV-Export an den Steuerberater.

Fachprozess-Erzählung & KI-Architektur Workflows & Lifecycles (2) Fachprozesse & Capabilities (12) Data Models & Fields (2) Entry Points (UI & APIs) (11) Regulatory & Compliance

⚡ Workflows & Lifecycles

Benutzerbefehl: payment matching agent `plan:command_payment_matching_agent`

Geprüfter Durable-Plan (durable_plan), Start: manual_command.

1. payment_matching_agent

payment_matching_agent

{"key": "execute_command", "label": "Befehl prüfen, ausführen oder zur Freigabe vorlegen", "adapter": "agent.execute", "agent": "payment_matching_agent", "condition_fact": null}

Aktionen: payment_matching_agent

Zahlung `status:payment`

Beobachtbare Zustandsmaschine (observable_only). Übergänge hier nicht erzwungen — siehe Service-Validierung.

1. unmatched

unmatched

Status «unmatched» der Zustandsmaschine Zahlung.

2. matched

matched

Status «matched» der Zustandsmaschine Zahlung.

3. confirmed

confirmed

Status «confirmed» der Zustandsmaschine Zahlung.

⚙️ Fachprozesse & Capabilities (System-Fachlogik)

Registrierte Fachoperationen und System-Capabilities dieses Moduls zur Steuerung von Workflows, Kaskaden und KI-Agenten.

Gesamt: 12 manual_entry: 1 engine: 6 operator_surface: 1 engine_step: 2 durable_plan: 1 observable_only: 1

Capability & Schlüssel	Fachliche Bezeichnung	Ausführung / Coverage	Risikostufe & Freigabe	Effekte & Kaskaden
Agent-Einstieg payment_matching_agent `agent_entry:payment_matching_agent`	Agent-Einstieg payment_matching_agent Quelle: `code:module_agent_map`	manual_entry	✓ Auto	Keine Seiteneffekte deklariert
Zahlung auf Rechnung buchen `capability:invoice.register_payment` Op: `invoice.register_payment`	Intent: `record_payment` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`payment.recorded`
Inkasso `capability:payment.collection.assign` Op: `payment.collection.assign`	Objekt: `payment` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`payment.collection.assign`
Mahnlauf `capability:payment.dunning.run` Op: `payment.dunning.run`	Objekt: `dunning_run` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`payment.dunning.run`
Zahlung zuordnen `capability:payment.match_invoice` Op: `payment.match_invoice`	Intent: `match_payment` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`payment.matched`
SEPA-Export `capability:payment.sepa.export` Op: `payment.sepa.export`	Objekt: `payment_batch` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`payment.sepa.export`
Zahlungseingang erfassen `capability:register_invoice_payment` Op: `register_invoice_payment`	Objekt: `invoice` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`payment.registered` `invoice.payment_recorded`
payment: create form `form_surface_anchor:payment.create`	Objekt: `payment` Quelle: `code:erp_form_surface`	operator_surface	✓ Auto	Keine Seiteneffekte deklariert
match payment `gateway:match_payment` Op: `match_payment`	match payment Quelle: `code:engine_facade`	⚙️ Engine	✓ Auto	Keine Seiteneffekte deklariert
unmatch payment `gateway:unmatch_payment` Op: `unmatch_payment`	unmatch payment Quelle: `code:engine_facade`	⚙️ Engine	✓ Auto	Keine Seiteneffekte deklariert
Benutzerbefehl: payment matching agent `plan:command_payment_matching_agent`	Benutzerbefehl: payment matching agent Quelle: `code:reviewed_execution_plan`	durable_plan	✓ Auto	Keine Seiteneffekte deklariert
Zahlung `status:payment`	Objekt: `payment` Quelle: `code:status_machine`	observable_only	✓ Auto	Keine Seiteneffekte deklariert

🧠 Fachprozess-Erzählung & Dual Knowledge Architektur

Synthese aus der ideologischen Blaupause (Meta-Fachlogik / Soll), der faktischen System-Implementierung (System-Fachlogik / Ist) und No-Code Customizing für KI-Consultants.

Dual Knowledge Layer

📖

Der durchgängige Businessprozess im Detail (End-to-End Fließtext-Erzählung)

Der durchgängige Rechnungs- und Buchhaltungsprozess in der betrieblichen Praxis

Die Finanzbuchhaltung ist das bilanzielle und steuerliche Rückgrat jedes Unternehmens. Centurio ERP verbindet hochautomatisierte Abrechnungsworkflows mit strikter Einhaltung deutscher und europäischer Rechnungslegungs- und Steuervorschriften.

1. Rechnungserstellung & Belegursprung (Billing Trigger)

Ausgangsrechnungen (AR) entstehen aus verschiedenen betrieblichen Leistungsquellen:

Auslieferung von Waren (sales): Sobald der Warenausgang für einen Verkaufsauftrag gebucht ist, stößt das System die Faktura an (cap:invoices.invoice.create_from_order).
Abgeschlossene Werkstatt- und Außendienstaufträge (workorders, fieldservice): Nach digitaler Kundensignatur auf dem Abnahmeprotokoll werden verbaute Ersatzteile und geleistete Arbeitsstunden zur Rechnung fakturiert.
Wiederkehrende Verträge & Mieten (contracts, rental): Die automatische Abrechnungs-Engine scannt am Monats- oder Quartalsersten alle aktiven Dauerverträge und erzeugt die zyklischen Rechnungen.
Gutschriften & Korrekturen (returns): Bei Reklamationen oder Rücksendungen wird eine Rechnungskorrektur mit negativer Verbindlichkeit generiert.

2. Gesetzliche Pflichtangaben & E-Rechnungsstandard (ZUGFeRD / XRechnung)

Seit der E-Rechnungspflicht im B2B-Geschäft generiert Centurio ERP jede Rechnung zweifach:

Menschlesbares PDF: Gestaltet nach Corporate Design mit allen handels- und steuerrechtlichen Pflichtangaben nach § 14 UStG (Rechnungsdatum, lückenlose Rechnungsnummer, Steuernummer/USt-IdNr., Anschriften, Lieferzeitpunkt, Steuersätze und -beträge).
Strukturierte XML-Daten nach EU-Norm EN 16931:
- ZUGFeRD 2.2 / Factur-X (Profil EN 16931 / Comfort): Die XML-Datei ist als unsichtbarer Anhang direkt in die PDF-Datei eingebettet (Hybridrechnung).
- Reine XRechnung (CII/UBL): Für Behördenkunden (B2G) mit Angabe der verbindlichen Leitweg-ID.

3. Festschreibung nach GoBD (Immutability & Final Lock)

Vor dem Versand an den Kunden wird die Rechnung über den systemgeprüften Gateway gw:invoice_finalization@v1 festgeschrieben (cap:invoices.invoice.finalize):

Schreibschutz: Nach diesem Schritt ist die Rechnung rechtlich existent und kann unter keinen Umständen mehr gelöscht oder geändert werden.
Transaktionale Buchung: Der Rechnungsbetrag wird unmittelbar auf das Erlöskonto (z.B. 8400 Erlöse 19% USt nach SKR03) und das Steuerkonto (1776 Umsatzsteuer) verbucht.
Anlage des Offenen Postens (OP): Im Debitorenkonto des Kunden entsteht ein offener Posten mit Fälligkeitsdatum und Skontofrist.

4. Versand & Bereitstellung (Multi-Channel Dispatch)

Die festgeschriebene Rechnung wird per E-Mail mit digitalem ZUGFeRD-Anhang an die hinterlegte Rechnungsadresse versandt (cap:invoices.invoice.send).
Im B2B-Kundenportal (portal) wird die Rechnung sofort in der Rechnungsübersicht des Kunden zum Download bereitgestellt.

5. Zahlungsabgleich & Elektronischer Kontoauszug (Bank Reconciliation)

Zahlungseingänge werden hochgradig automatisiert verarbeitet:

Kontoauszugsabruf (CAMT.053 / MT940 / EBICS): Über das Bankenmodul (banking) ruft das System täglich die elektronischen Kontoauszüge aller Geschäftsbanken ab.
Automatisches Matching: Die Reconciliation-Engine gleicht Verwendungszwecke, Rechnungsnummern, Beträge und IBANs gegen die offenen Debitorenposten ab (cap:payments.payment.auto_reconcile).
Skontoprüfung: Zahlt der Kunde innerhalb der Skontofrist unter Abzug von Skonto (z.B. 2%), bucht das System die Skontodifferenz automatisch auf das Skontoaufwandskonto (8736 nach SKR03).
Zahlungsausgleich: Der offene Posten wird geschlossen; der Rechnungsstatus wechselt auf Bezahlt (paid).

6. Mehrstufiges Mahnwesen (Dunning Run)

Bleiben Zahlungen nach Fälligkeit aus, greift das automatisierte Mahnwesen:

Das System ermittelt täglich alle überfälligen Rechnungen unter Berücksichtigung von Kulanzfristen.
Mahnlauf: Über cap:invoices.dunning.run werden Mahnstufen durchlaufen:
- Zahlungserinnerung: Höfliche Erinnerung ohne Gebühren.
- 1. Mahnung: Nach 10 Tagen mit Mahngebühr.
- 2. Mahnung: Nach weiteren 10 Tagen mit Verzugszinsen nach BGB § 288 (9 Prozentpunkte über Basiszinssatz im B2B).
- 3. Mahnung / Inkasso: Übergabe an Rechtsabteilung oder Inkassodienstleister; Kreditsperre für den Kunden im Vertriebsmodul.

7. Hauptbuch, Kontenrahmen & DATEV-Export

Doppelte Buchführung: Alle buchhalterischen Vorgänge (Rechnungen, Zahlungseingänge, Bankspesen, Abschreibungen) werden im Hauptbuchjournal geführt.
Kontenrahmen: Unterstützung standardisierter Kontenrahmen (SKR03 und SKR04 der DATEV).
Steuerberaterexport: Zum Monats- oder Quartalsabschluss generiert das Exportmodul (exports) den DATEV-ASCII-Buchungsstapel inklusive Belegbild-Verknüpfung (cap:exports.datev.generate_batch), der direkt in DATEV Kanzlei-Rechnungswesen eingelesen werden kann.

🏛️

Meta-Fachlogik: Ideologische Blaupause, Soll-Weltbild & Normen

Meta-Fachlogik: Die ideologische Blaupause & das normative Weltbild

Die Meta-Fachlogik der Buchhaltung stützt sich auf die Grundsätze ordnungsmäßiger Buchführung (GoB/GoBD), das Handelsgesetzbuch (HGB), das Umsatzsteuergesetz (UStG) und europäische E-Rechnungsrichtlinien.

1. Grundsätze ordnungsmäßiger Buchführung (GoB / GoBD)

Das Belegprinzip: Keine Buchung ohne Beleg. Jede Journalbuchung muss zwingend auf einen rechtssicheren, nachvollziehbaren Beleg zurückzuführen sein.
Grundsatz der Unveränderbarkeit (§ 146 Abs. 4 HGB / GoBD Rz. 58):
- Eine Buchung oder ein Beleg darf nicht in einer Weise verändert werden, dass der ursprüngliche Inhalt nicht mehr feststellbar ist.
- Das Soll-Modell verbietet das Überschreiben, Löschen oder Zurücksetzen finalisierter Rechnungen. Jede Korrektur muss über einen eigenständigen Gegenbeleg (Stornorechnung / Rechnungskorrektur) mit eindeutigem Referenzbezug erfolgen.
Zeitgerechtheit & Lückenlosigkeit: Unbare Geschäftsvorfälle sind zeitnah (spätestens innerhalb von 10 Tagen) zu erfassen. Rechnungsnummern müssen lückenlos fortlaufend sein.

2. Umsatzsteuerrecht & E-Rechnungs-Standards

Umsatzsteuergesetz (§ 14, § 14a UStG):
- Zwingende Pflichtbestandteile: Vollständiger Name und Anschrift von Leistendem und Leistungsempfänger, Steuernummer oder USt-IdNr., Ausstellungsdatum, fortlaufende Nummer, Menge und handelsübliche Bezeichnung der Gegenstände, Zeitpunkt der Lieferung/Leistung, nach Steuersätzen aufgeschlüsseltes Entgelt sowie gesondert ausgewiesene Steuerbeträge.
Richtlinie 2014/55/EU & Wachstumschancengesetz:
- Verpflichtung zur strukturierten elektronischen Rechnung im B2B-Geschäftsverkehr (EN 16931). Das Soll-Modell betrachtet reine PDF-Rechnungen ohne strukturierte XML-Syntax als veraltet bzw. im B2B ab 2025/2026 als unzulässig.

3. Invarianten des Soll-Modells

Keine Rechnung ohne eindeutige, lückenlose Belegnummer aus einem geschützten Nummernkreis.
Eine festgeschriebene Rechnung darf niemals physikalisch aus der Datenbank gelöscht werden.
Soll und Haben müssen bei jeder Journalbuchung exakt ausgeglichen sein (Summe Soll = Summe Haben).
Offene Posten dürfen nur durch nachgewiesene Zahlungseingänge, genehmigte Gutschriften oder ausgebuchte Mahndifferenzen geschlossen werden.

Normbezug für `payments`

Prüfkatalog Standards-Registry v2026.10.1. Dieser Abschnitt ordnet Prüfreferenzen zu und stellt nicht fest, dass das Modul eine Norm einhält; keine Kataloganforderung ist als PASS bewertet.

Geführte Prüfreferenzen:

de-gobd-2025, GoBD – Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff, Ausgabe GoBD, Fassung 2019-11-28, geändert 2024-03-11 und 2025-07-14. Art: guidance. Nur öffentliche Zusammenfassung. Keine Volltextprüfung. Keine modulspezifische Kataloganforderung. Die Zuordnung bleibt eine Prüfreferenz.

Im Auditauftrag zusätzlich genannt und nicht im Prüfkatalog v2026.10.1: ISO 20022, EPC SEPA Rulebooks. Dafür gibt es hier keine Klausel und keine Aussage, dass eine Vorgabe eingehalten wird.

Plattformweite Katalogwerke mit Geltungsbereich all (unter anderem WCAG 2.2, EN 301 549 V4.1.1, ISO 9241-110:2020, ISO 9241-210:2019, ISO/IEC 25010:2023, ISO 9001:2026, ISO/IEC 27001:2022, APQC PCF 8.0, DSGVO, EU AI Act) umfassen dieses Modul mit. Wo der Volltext fehlt, bleibt der Zugang ohne Quelle, lizenzpflichtig oder nur als öffentliche Zusammenfassung gekennzeichnet. Auch diese Nennung weist keine eingehaltene Vorgabe nach.

⚙️

Systemische Fachlogik: Faktische Umsetzung in Centurio ERP & Capabilities

Systemische Fachlogik: Die faktische Umsetzung in Centurio ERP

Die System-Fachlogik dokumentiert die Realisierung in den Modulen invoices, accounting, finance und exports.

1. Datenmodelle & Semantische Schicht (ORM)

Invoice: Rechnungskopf (Felder: id, tenant_id, invoice_number, invoice_type [outward, credit_note, correction, cancellation], status, customer_id, invoice_date, due_date, total_net_amount, total_tax_amount, total_gross_amount, currency, zugferd_xml, is_locked).
InvoiceLine: Rechnungspositionen (Felder: invoice_id, product_id, quantity, unit_price, tax_rate, revenue_account_code, cost_center_id).
GeneralLedgerEntry: Buchungsjournalzeile (Felder: id, entry_number, booking_date, account_code, contra_account_code, debit_amount, credit_amount, reference_doc_id, is_settled).
OpenItem: Offener Posten (Felder: invoice_id, customer_id, due_date, open_amount, paid_amount, dunning_level).
BankStatementTransaction: Bankkontoauszugsbewegung (Felder: account_iban, valuta_date, amount, remittance_info, matched_invoice_id).

2. Das Capability-Register

cap:invoices.invoice.create: Anlegen eines Rechnungsentwurfs.
cap:invoices.invoice.finalize: GoBD-Festschreibung und Sperrung der Rechnung.
cap:invoices.invoice.generate_zugferd: Erzeugung der EN 16931 konformen ZUGFeRD-XML-Syntax.
cap:invoices.invoice.send: Versand der Hybridrechnung per E-Mail/Portal.
cap:invoices.invoice.cancel: Erzeugung einer korrespondierenden Stornorechnung.
cap:payments.payment.auto_reconcile: Automatischer Kontoauszugsabgleich gegen offene Posten.
cap:invoices.dunning.run: Ausführung des regelbasierten Mahnlaufs.
cap:exports.datev.generate_batch: Erstellung des DATEV-kompatiblen ASCII-Buchungsstapels.

3. Der Gateway `gw:invoice_finalization@v1`

Sichert die fiskalische Rechtsverbindlichkeit ab:

Plausibilitätsprüfung: Prüft USt-IdNr., Steuersätze, Pflichtfelder nach § 14 UStG und rechnerische Summenintegrität.
Festschreibung: Setzt Invoice.is_locked = true und Invoice.status = 'finalized'.
Journalbuchung: Erzeugt atomar die Soll- und Haben-Zeilen in GeneralLedgerEntry.
OP-Anlage: Bucht den offenen Posten in OpenItem.
Outbox-Signal: Feuert INVOICE_FINALIZED_EVENT.

4. Statusmodelle

Rechnungs-Status: draft (Entwurf) ➔ finalized (Festgeschrieben/Offen) ➔ partially_paid (Teilbezahlt) ➔ paid (Ausgeglichen) oder cancelled (Storniert).
Mahnstufen: none (0) ➔ reminder (Erinnerung) ➔ level_1 ➔ level_2 ➔ level_3 (Inkasso).

🤖

KI-Consultant Leitfaden: Customizing- & No-Code-Konzept (Soll-Ist-Synthese)

AI Solution Architect Blueprint

KI-Consultant Blueprint: Customizing & No-Code Architektur

Anleitung für Solution Architects zur Einrichtung der Finanz- und Fakturierungsworkflows.

1. Kundenanforderungsanalyse

Welcher Kontenrahmen wird genutzt (SKR03 oder SKR04)?
Welche Skontoregeln und Zahlungsziele gelten standardmäßig (z.B. 14 Tage 2% Skonto, 30 Tage netto)?
Sollen Behördenkunden (B2G) mit zwingender Leitweg-ID und reiner XRechnung bedient werden?

2. No-Code Zusatzfelder (Custom Fields)

Im No-Code Studio (/semantic/customizing):

Auf Invoice:
- leitweg_id (Text): Zwingend für XRechnung an Bundes- und Landesbehörden.
- cost_unit_code (Text): Kostenträgerzuordnung für die Kostenstellenrechnung.
- buyer_reference (Text): Einkaufsreferenz des Kunden (Bestellnummer).
Auf OpenItem:
- dispute_reason (Auswahlliste: Preisklaerung, Mangelruege, Falschlieferung): Sperrt den Mahnlauf bei berechtigten Kundenreklamationen.

3. No-Code Workflow Canvas DAGs

Blueprint A: Automatischer Rechnungsversand nach Warenausgang (Auto-Invoice DAG)

Trigger-Node: Event ORDER_DISPATCHED aus dem Lagermodul.
Condition-Node: order.customer.invoice_generation_policy == 'immediate'.
Action-Node 1: Rufe cap:invoices.invoice.create_from_order auf.
Action-Node 2: Rufe Gateway gw:invoice_finalization@v1 auf.
Action-Node 3: Versende ZUGFeRD-PDF per E-Mail an Rechnungs-Empfänger.

Blueprint B: Automatisches Mahnwesen mit Dispute-Sperre (Dunning DAG)

Trigger-Node: Scheduled Cron (0 6 * * 1) – Wöchentlicher Mahnlauf.
Condition-Node: open_item.days_overdue > 14 AND open_item.dispute_reason == null.
Action-Node: Eskaliere Mahnstufe (level_1), berechne 5,00 € Mahngebühr und generiere Mahnschreiben mit QR-Zahlcode (GiroCode).

📚 Operative Prozessbegriffe & Transaktionsschnittstellen

Zentrale Fachbegriffe im Prozesszusammenhang (Operatives Modell)

ZUGFeRD & XRechnung

Europäische E-Rechnungsstandards (EN 16931) zur strukturierten, maschinenlesbaren Rechnungsübermittlung.

GoBD-Festschreibung

Revisionssichere Unveränderbarkeit von Buchungsbelegen nach deren Abschluss.

Offene Posten (OP)

Verzeichnis noch nicht ausgeglichener Forderungen (Debitoren) oder Verbindlichkeiten (Kreditoren).

Bankabstimmung (Reconciliation)

Automatisierter Abgleich von Kontoauszugsbewegungen gegen offene Rechnungen.

SKR03 / SKR04

Standardkontenrahmen der DATEV für die Gliederung von Finanzbuchhaltungskonten.

Mahnlauf

Periodischer systematischer Prozess zur Beitreibung überfälliger Kundenforderungen.

3-Wege-Abgleich

Prüfung von Bestellung, Wareneingang und Eingangsrechnung vor Zahlungsfreigabe.

📥 Eingänge & Trigger (Inputs)

Lieferscheinquittierung aus dem Warenausgang des Lagers
Abgeschlossene Arbeitsaufträge mit digitaler Kundensignatur
Abrechnungszyklen aus Miet- und Serviceverträgen
Elektronische Bankkontoauszüge (CAMT.053 / MT940)

📤 Ausgänge & Arbeitsergebnisse (Outputs)

GoBD-konforme ZUGFeRD-2.2- und XRechnungs-Dokumente
Doppelte Buchungsjournal-Einträge im Hauptbuch (General Ledger)
Automatisierte Zahlungsausgleiche und Skontobuchungen
DATEV-kompatible Exportstapel für Steuerberater und Wirtschaftsprüfer
Mahnungsdokumente und Verzugszinsaufstellungen

⚡ Kaskaden & Folgeprozesse (Cascades)

invoice_finalized -> open_item_created: Sofortige Anlage der offenen Forderung
payment_matched -> close_open_item: Schließen der Forderung und Auslösen des Rechnungsstatus bezahlt
invoice_overdue -> trigger_dunning_pipeline: Einsteuern in den Mahnlauf
batch_exported -> lock_accounting_period: Periodenabschluss mit Schreibschutz

🛡️ Nebenprozesse & Resilienz

Rechnungskorrektur und Storno bei berechtigter Reklamation
Manuelle Klärung von Restbeträgen und Rundungsdifferenzen beim Bankabgleich
Zahlungssperren bei strittigen Eingangsrechnungen (Dispute Management)
Währungskursdifferenzbuchung bei Forderungen in Fremdwährungen

💡 No-Code Checkliste & Praxistipps

Kontenrahmen (SKR03 oder SKR04) passend zur Steuerberaterkanzlei wählen
Standard-Zahlungsziele, Skontosätze und Mahngebühren parametrieren
DATEV-Beraternummer und Mandantennummer in den Exporteinstellungen pflegen
No-Code Zusatzfelder für Leitweg-ID (Behördenrechnung) auf Invoice anlegen

🗄️ Data Models & Fields

PaymentOrders payment_orders RLS Aktiv

14 Fields / Columns

Tabelle payment_orders

Feldname	Data Type	Required	Schlüssel	Functional Meaning
`kind`	`VARCHAR(16)`	Ja *	-	Feld kind
`package_amount`	`NUMERIC(14, 2)`	Ja *	-	Feld package_amount
`package_gb`	`INTEGER`	Nein	-	Feld package_gb
`provider`	`VARCHAR(16)`	Ja *	-	Feld provider
`provider_session_id`	`VARCHAR(255)`	Nein	-	Feld provider_session_id
`status`	`VARCHAR(16)`	Ja *	-	Feld status
`created_by`	`UUID`	Nein	-	Feld created_by
`paid_at`	`DATETIME`	Nein	-	Feld paid_at
`topup_id`	`UUID`	Nein	FK ➔ ai_budget_topups.id	Feld topup_id
`rental_booking_id`	`UUID`	Nein	FK ➔ rental_bookings.id	Feld rental_booking_id
`id`	`UUID`	Nein	PK	Feld id
`tenant_id`	`UUID`	Ja *	FK ➔ organizations.id	Feld tenant_id
`created_at`	`DATETIME`	Ja *	-	Feld created_at
`updated_at`	`DATETIME`	Ja *	-	Feld updated_at

Payments payments RLS Aktiv

24 Fields / Columns

Tabelle payments

Feldname	Data Type	Required	Schlüssel	Functional Meaning
`legal_entity_id`	`UUID`	Nein	FK ➔ legal_entities.id	Feld legal_entity_id
`transaction_date`	`DATE`	Ja *	-	Feld transaction_date
`value_date`	`DATE`	Nein	-	Feld value_date
`amount`	`NUMERIC(14, 2)`	Ja *	-	Feld amount
`currency`	`VARCHAR(3)`	Ja *	-	Feld currency
`direction`	`VARCHAR(48)`	Ja *	-	Feld direction
`payment_method`	`VARCHAR(32)`	Nein	-	Feld payment_method
`counterparty_name`	`VARCHAR(255)`	Nein	-	Feld counterparty_name
`counterparty_iban`	`VARCHAR(34)`	Nein	-	Feld counterparty_iban
`reference`	`TEXT`	Nein	-	Feld reference
`bank_transaction_id`	`VARCHAR(128)`	Ja *	-	Feld bank_transaction_id
`invoice_id`	`UUID`	Nein	FK ➔ invoices.id	Feld invoice_id
`bank_account_id`	`UUID`	Nein	FK ➔ bank_accounts.id	Feld bank_account_id
`matching_confidence`	`NUMERIC(4, 3)`	Nein	-	Feld matching_confidence
`status`	`VARCHAR(48)`	Ja *	-	Feld status
`id`	`UUID`	Nein	PK	Feld id
`tenant_id`	`UUID`	Ja *	FK ➔ legal_entities.tenant_id	Feld tenant_id
`created_at`	`DATETIME`	Ja *	-	Feld created_at
`updated_at`	`DATETIME`	Ja *	-	Feld updated_at
`created_by`	`UUID`	Nein	-	Feld created_by
`updated_by`	`UUID`	Nein	-	Feld updated_by
`source_type`	`VARCHAR(32)`	Nein	-	Feld source_type
`source_id`	`UUID`	Nein	-	Feld source_id
`metadata`	`JSONB`	Ja *	-	Feld metadata

🔌 Entry Points (UI & APIs)

Art	Method	Endpoint / Path	Titel & Zweck	Required Role
⚡ REST API	DELETE	`/api/v1/payments/{payment_id}`	delete_payment Semantic binding: operator_surface; mutation=True	`payments`
⚡ REST API	GET	`/api/v1/payments`	list_payments Semantic binding: inventory_only; mutation=False	`payments`
⚡ REST API	GET	`/payments`	payments_page Semantic binding: inventory_only; mutation=False	`payments`
⚡ REST API	GET	`/payments/new`	payment_create_page Semantic binding: inventory_only; mutation=False	`payments`
⚡ REST API	GET	`/payments/{payment_id}`	payment_detail_page Semantic binding: inventory_only; mutation=False	`payments`
⚡ REST API	GET	`/payments/{provider}/return`	payments_return Semantic binding: inventory_only; mutation=False	`payments`
⚡ REST API	POST	`/api/v1/payments`	create_payment Semantic binding: operator_surface; mutation=True	`payments`
⚡ REST API	POST	`/api/v1/payments/import-statement`	import_bank_statement Semantic binding: operator_surface; mutation=True	`payments`
⚡ REST API	POST	`/api/v1/payments/{payment_id}/assign-account`	assign_bank_account Semantic binding: operator_surface; mutation=True	`payments`
⚡ REST API	POST	`/api/v1/payments/{payment_id}/match`	match_payment Semantic binding: operator_surface; mutation=True	`payments`
⚡ REST API	POST	`/api/v1/payments/{payment_id}/unmatch`	unmatch_payment Semantic binding: operator_surface; mutation=True	`payments`

🛡️ Regulatory & Compliance

Dieses Modul unterliegt folgenden gesetzlichen, regulatorischen und Revisionsstandards:

GoBD Nachvollziehbarkeit
Mandanten-Isolation (PostgreSQL RLS)