Centurio System & Module Documentation
🏛️ Platform Architecture 🔑 Login
All Modules / sales_billing / E-Commerce & Marktplätze
📘

E-Commerce & Marktplätze

ecommerce sales_billing 🛡️ RLS Protected

E-Commerce & Marktplätze — aus Code abgeleitete Prozess- und API-Dokumentation.

Fachliche Bestimmung: Verkauf & Kundenaufträge steuert die verbindliche vertragliche Auftragsabwicklung: Erfassung und Bestätigung von Kundenaufträgen über Omnichannel-Schnittstellen (B2B, Shop, EDI, POS), strikte Kreditlimit- und Bonitätsprüfung, Lieferterminierung nach CTP (Capable-to-Promise), automatische Verzweigung in Fertigungs- (MTO), Lager- (MTS) oder Streckenkaskaden (Dropshipping) und die lückenlose Übergabe an Fakturierung und Logistik.

⚡ Workflows & Lifecycles

E-Commerce Bestellimport & Bestandsabgleich shop_order_synchronization

Vollautomatischer Import externer Shop-Bestellungen (Shopify, WooCommerce), Zahlungsverifikation und Bestandsreservierung.

sequenceDiagram autonumber actor Customer as Online-Käufer participant Shop as Webshop (Shopify/Woo) participant EcomModule as E-Commerce Connector participant Sales as Verkaufsauftrags-Engine participant Inventory as Lager & Bestandsführung Customer->>Shop: Bestellung aufgeben & bezahlen Shop->>EcomModule: Webhook: order.created (JSON) EcomModule->>Sales: Verkaufsauftrag generieren (Preise, MwSt, Kunde) Sales->>Inventory: ATP-Reservierung für bestellte Artikel Inventory-->>Sales: Bestand erfolgreich reserviert Sales-->>Shop: Auftrags-ID & Tracking-Zusage bestätigt
1. ORDER_INGEST
Shop-Bestellung empfangen
Webhook des Onlineshops trifft ein und übermittelt Bestelldaten und Kundendaten.
Aktionen: HMAC validieren, Payload parsen
2. PAYMENT_VERIFY
Zahlung verifizieren
Prüfung ob Zahlung (PayPal, Stripe, Klarna) autorisiert oder verbucht ist.
Aktionen: Zahlungsstatus abgleichen, Zahlungsreferenz binden
3. ORDER_BIND
Auftrag erzeugen
Anlage des Verkaufsauftrags mit Kundenmatching oder Neuanlage des Kundenstamms.
Aktionen: Kundennummer zuweisen, Preise & Steuern validieren
4. STOCK_RESERVE
Bestand reservieren
Sofortige ATP-Bestandsreservierung im Versandlager und Rückmeldung an den Shop.
Aktionen: Reservierungsbeleg, Restbestand an Shop pushen

⚙️ Fachprozesse & Capabilities (System-Fachlogik)

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

Gesamt: 3 manual_entry: 1 engine: 1 engine_step: 1
Capability & Schlüssel Fachliche Bezeichnung Ausführung / Coverage Risikostufe & Freigabe Effekte & Kaskaden
Agent-Einstieg billing_general_agent agent_entry:billing_general_agent
Agent-Einstieg billing_general_agent
Quelle: code:module_agent_map
manual_entry
✓ Auto
Keine Seiteneffekte deklariert
E-Commerce-Bestellung übernehmen capability:ingest_ecommerce_order
Op: ingest_ecommerce_order
Intent: ingest_ecommerce_order
Quelle: code:capability_registry
⚙️ Engine
✓ Auto Risiko: business_record
  • engine:ingest_ecommerce_order
E-Commerce-Bestellung übernehmen gateway:ecommerce_order_ingest
Op: ingest_ecommerce_order
E-Commerce-Bestellung übernehmen
Quelle: code:reviewed_gateway
⚙️ Engine
✓ 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 Verkaufsprozess in der betrieblichen Praxis

Der Verkaufsauftrag ist das zentrale juristische und operative Bindeglied zwischen Vertrieb, Fertigung, Lager und Debitorenbuchhaltung. Er manifestiert den gegenseitigen Vertrag und steuert alle nachgelagerten Erfüllungsprozesse.

1. Auftragseingang & Omnichannel-Erfassung (Order Ingestion)

Kundenaufträge gelangen über unterschiedliche Kanäle in das System:

  • Angebotskonvertierung (quotes): Der Kunde nimmt ein Angebot an; der Annahme-Gateway generiert 1:1 den Auftrag (cap:sales.sales_order.create_from_quote).
  • E-Commerce & Marktplätze (ecommerce): Shop-Bestellungen (Shopify, WooCommerce, Magento) treffen per Webhook ein. Das System validiert Preise, Steuern und Kundendaten und legt den Auftrag vollautomatisch an (cap:sales.sales_order.create_from_ecommerce).
  • Direktbestellung per E-Mail (inbox): E-Mails bekannter Kunden mit Bestellabsicht werden von der KI analysiert, Positionen gematcht und als Auftragsentwurf bereitgestellt.
  • Kassensystem Point of Sale (pos): Bar- und Kartentransaktionen im Ladengeschäft erzeugen sofortige Auftrags- und Warenausgangsbuchungen.
  • Manuelle Auftragserfassung: Der Innendienst erfasst Kundenwünsche direkt im Webportal.

2. Bonitätsprüfung, Kreditlimit & Zahlungsbedingungen

Vor der Annahme prüft das System das finanzielle Ausfallrisiko:

  • Kreditlimitprüfung: Das System ermittelt das Gesamtexposure des Kunden: $$\text{Obligo} = \text{Offene Posten (OP)} + \text{Noch nicht fakturierte Aufträge} + \text{Aktueller Auftrag}$$ Übersteigt das Obligo das im Kundenstamm (customers) hinterlegte Kreditlimit, sperrt das System die automatische Bestätigung. Der Auftrag wechselt in den Zustand Kreditsperre (credit_hold) und erfordert eine explizite Freigabe durch die Finanzbuchhaltung (cap:sales.sales_order.approve_credit_override).
  • Zahlungsbedingungen & Vorkasse: Bei Neukunden oder schlechter Bonität erzwingt das System Vorkasse: Der Auftrag wird erst für die Logistik freigegeben, wenn der Zahlungseingang auf dem Bankkonto verbucht ist.

3. Auftragsbestätigung (AB) & Vertragsschluss

  • Ist die kaufmännische Prüfung erfolgreich, wechselt der Auftrag auf Bestätigt (confirmed).
  • Auftragsbestätigung: Das System generiert die rechtsverbindliche Auftragsbestätigung nach HGB § 362 / BGB § 145 mit Angabe von Liefertermin, Zahlungsziel, Incoterms und Leistungsbeschreibung (cap:sales.sales_order.confirm_and_send).

4. Lieferterminierung & CTP-Verfügbarkeitsprüfung (Capable-to-Promise)

Parallel zur Bestätigung erfolgt die logistische Einplanung:

  • Lagerware (Make-to-Stock - MTS): Das System prüft die ATP-Verfügbarkeit. Sind Artikel auf Lager, werden sie sofort reserviert (cap:inventory.stock.reserve).
  • Fertigungsware (Make-to-Order - MTO): Handelt es sich um Sonderanfertigungen, errechnet die CTP-Engine (Capable-to-Promise) anhand der aktuellen Maschinenbelegung und Materialbeschaffungszeiten den frühestmöglichen Fertigstellungstermin. Die Verkaufsauftragszeile dockt direkt an das Fertigungsmodul an (cap:assembly.create_order_from_order_line).
  • Streckengeschäft (Dropshipping): Ist der Artikel als Streckenposition markiert, generiert das System eine direkte Beschaffungsanforderung an den Lieferanten (dropship), der die Ware direkt an den Endkunden liefert.

5. Teillieferungen & Versandsteuerung

  • Lieferpräferenzen: Der Kunde kann wählen zwischen Komplettlieferung (Versand erst, wenn alle Positionen verfügbar sind) oder Teillieferung erlaubt.
  • Warenausgangsfreigabe: Sobald reservierte Mengen im Lager bereitstehen, generiert das System den Lieferauftrag (cap:inventory.picking.generate). Nach Warenausgangsbuchung schaltet die Auftragszeile auf geliefert.

6. Fakturierung & Belegfluss (Invoice Trigger)

  • Je nach Vereinbarung erfolgt die Abrechnung:
    • Sofortfaktura nach Lieferung: Der bestätigte Lieferschein stößt unmittelbar die Ausgangsrechnung im Rechnungsmodul an (invoices).
    • Sammelrechnung: Lieferungen eines Monats werden zu einer gebündelten Monatsrechnung zusammengefasst.
    • Abschlags- und Schlussrechnung: Bei Projekten und Großaufträgen werden Meilensteinzahlungen nach Zahlungsplan abgerechnet.

7. Auftragsabschluss & Reklamationsanbindung

  • Sind alle Positionen geliefert und vollständig fakturiert, wechselt der Verkaufsauftrag über den Abschluss-Gateway in den Status Abgeschlossen (completed).
  • Treten nach Lieferung Mängel auf, dockt das Reklamationsmodul (returns) direkt an die Verkaufsauftragsnummer an, um Retouren, Ersatzlieferungen oder Gutschriften zuzuordnen.
🏛️

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

Meta-Fachlogik: Die ideologische Blaupause & das normative Weltbild

Die Meta-Fachlogik des Verkaufs basiert auf handelsrechtlichen Vorschriften (HGB), zivilrechtlichem Vertragsrecht (BGB), internationalen Handelsklauseln (Incoterms 2020) und Grundsätzen kaufmännischen Risikomanagements.

1. Handelsrechtliche Grundlagen & Vertragsschluss

  • Kaufmännisches Bestätigungsschreiben (HGB § 362 analog):
    • Im B2B-Geschäftsverkehr fixiert die Auftragsbestätigung den verbindlichen Vertragsinhalt. Widerspricht der Kunde nicht unverzüglich, gilt der Inhalt als vereinbart.
    • Das Soll-Modell verlangt die lückenlose Dokumentation von Angebots- und Auftragsständen sowie den Ausschluss widersprüchlicher AGB (Kollision Allgemeiner Geschäftsbedingungen).
  • Leistungs- und Erfüllungsort (Incoterms 2020):
    • Definition des Gefahrenübergangs und der Kostenverteilung: z.B. EXW (Ab Werk), FCA (Frei Frachtführer) oder DAP (Geliefert benannter Ort). Das System muss den Gefahrenübergang exakt an die Lieferscheinbuchung koppeln.

2. Risikomanagement & Funktionstrennung (Segregation of Duties)

  • Kreditrisiko-Steuerung: Vertriebsmitarbeiter dürfen keine eigenmächtigen Krediterweiterungen vornehmen. Das Soll-Modell verlangt strikte Funktionstrennung zwischen Vertrieb (Umsatzorientierung) und Debitoren-Risikomanagement (Liquiditätssicherung).
  • Lieferverzug & Pönalen: Das System muss Lieferzusagen überwachen, um Schadensersatzforderungen oder Vertragsstrafen wegen Lieferverzugs (§ 286 BGB) proaktiv abzuwenden.

3. Invarianten des Soll-Modells

  1. Keine Auslieferung ohne bestätigten Auftrag oder autorisierte Freigabe.
  2. Keine Auftragsfreigabe bei Kreditlimitüberschreitung ohne Autorisierung durch Finance.
  3. Ein bestätigter Auftrag darf nachträglich nicht stillschweigend editiert werden; Änderungen erfordern Auftragsänderungsbelege.
  4. Fakturierte Positionen sind für Preisänderungen gesperrt.

Normbezug für ecommerce

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:

  • wcag-2.2, Web Content Accessibility Guidelines (WCAG) 2.2, Ausgabe W3C Recommendation 2023-10-05. Art: normative. Öffentlicher Text. Die Nennung ist keine Klauselprüfung. Keine modulspezifische Kataloganforderung. Die Zuordnung bleibt eine Prüfreferenz.

Im Auditauftrag zusätzlich genannt und nicht im Prüfkatalog v2026.10.1: GS1, PCI DSS. 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 im Kernmodul sales.

1. Datenmodelle & Semantische Schicht (ORM)

  • SalesOrder: Auftragskopf (Felder: id, tenant_id, order_number, customer_id, status, order_date, confirmed_delivery_date, total_net_amount, total_tax_amount, currency, incoterms, payment_term_id, shipping_address_id, billing_address_id).
  • SalesOrderLine: Auftragspositionen (Felder: sales_order_id, line_number, product_id, quantity, unit_price, discount_percent, fulfillment_type [stock, assembly, dropship], shipped_quantity, invoiced_quantity, status).
  • SalesOrderHold: Dokumentation von Liefersperren (Kreditlimit, Compliance-Check, manuelle Sperre).

2. Das Capability-Register

  • cap:sales.sales_order.create: Manuelle oder automatisierte Anlage eines Kundenauftrags.
  • cap:sales.sales_order.create_from_quote: Übernahme aller Daten aus einem Angebot.
  • cap:sales.sales_order.confirm_and_send: Bestätigung und PDF-Versand an den Kunden.
  • cap:sales.sales_order.check_credit_limit: Automatische Prüfung des Debitorenobergrenze.
  • cap:sales.sales_order.approve_credit_override: Entsperrung eines kreditsistierten Auftrags.
  • cap:sales.sales_order.reserve_stock: Auslösung der ATP-Reservierung im Lager.
  • cap:sales.sales_order.trigger_fulfillment: Kaskadierung an Lager (Pickauftrag), Fertigung (MTO) oder Dropship.
  • cap:sales.sales_order.cancel: Stornierung mit automatischer Auflösung aller Reservierungen.

3. Der Gateway gw:sales_order_fulfillment@v1

Der Erfüllungs-Gateway steuert die Übergabe an die Wertschöpfung:

  1. Validierung: Prüft Kreditstatus, steuerliche Plausibilität (z.B. USt-IdNr. bei innergemeinschaftlicher EU-Lieferung) und Vollständigkeit der Lieferadresse.
  2. Kaskadierung: Erzeugt transaktional die Reservierungen in inventory oder ruft cap:assembly.create_order_from_order_line auf.
  3. Statuswechsel: SalesOrder.status = 'processing'.
  4. Outbox-Signal: Feuert SALES_ORDER_FULFILLMENT_STARTED.

4. Statusmodelle

draft (Entwurf) ➔ credit_hold (Kreditsperre) ➔ confirmed (Bestätigt) ➔ processing (In Ausführung) ➔ partially_delivered (Teilgeliefert) ➔ delivered (Geliefert) ➔ invoiced (Fakturiert) ➔ completed (Abgeschlossen) oder cancelled (Storniert).

🤖

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

AI Solution Architect Blueprint

KI-Consultant Blueprint: Customizing & No-Code Architektur

Leitfaden für Solution Architects zur Einrichtung von Vertriebs-Workflows.

1. Kundenanforderungsanalyse

  • Welche Verkaufskanäle müssen synchronisiert werden (Webshop, EDI nach EDIFACT/VDA, Ladenkasse POS)?
  • Wie restriktiv soll die Kreditsperre greifen (strikter Stopp oder nur Warnhinweis)?
  • Werden Teillieferungen standardmäßig gebündelt oder sofort bei Teilverfügbarkeit versandt?

2. No-Code Zusatzfelder (Custom Fields)

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

  • Auf SalesOrder:
    • customer_order_reference (Text): Externe Bestellnummer des Kunden (z.B. PO-12345).
    • delivery_instructions (Mehrzeiliger Text): Sonderanweisungen für den Frachtführer (z.B. Hebebühne erforderlich, Aviso 1 Stunde vor Ankunft).
    • project_code (Text): Zuweisung zu übergeordnetem Kundenprojekt.
  • Auf SalesOrderLine:
    • customer_part_number (Text): Artikelnummer des Kunden zur Ausweisung auf Belegen.
    • serial_number_required (Checkbox): Erzwingt Seriennummernprüfung bei Auslagerung.

3. No-Code Workflow Canvas DAGs

Blueprint A: Automatischer Webshop-Bestellflow (E-Commerce Ingest DAG)
  • Trigger-Node: Webhook ecommerce.order.created.
  • Condition-Node: order.payment_status == 'paid' AND order.customer.is_fraud_suspect == false.
  • Action-Node 1: Erzeuge SalesOrder mit Status confirmed.
  • Action-Node 2: Führe cap:sales.sales_order.reserve_stock aus.
  • Branch-Node: Wenn alle Artikel lagernd ➔ Erzeuge sofort Warenausgangsauftrag; wenn Fehlteile ➔ Sende Push an Einkauf.
Blueprint B: Kreditsperren-Eskalation (Credit Hold DAG)
  • Trigger-Node: Event SALES_ORDER_CREDIT_HOLD.
  • Action-Node: Erzeuge dringende Prüfaufgabe für Debitorenbuchhaltung mit Ausweisung der überfälligen Rechnungen und des aktuellen Auftragswerts.
  • Freigabe-Gate: Erst nach Klick auf Limit erhöhen oder Einzelfreigabe erteilen wechselt der Auftrag in den Status confirmed.

📚 Operative Prozessbegriffe & Transaktionsschnittstellen

Zentrale Fachbegriffe im Prozesszusammenhang (Operatives Modell)
Auftragsbestätigung (AB)
Rechtsverbindliche Bestätigung des Vertragsschlusses mit Preisen, Terminen und Incoterms.
Kreditlimit & Obligo
Höchstgrenze des finanziellen Risikos eines Kunden aus offenen Rechnungen und laufenden Aufträgen.
CTP (Capable-to-Promise)
Prüfung der Lieferfähigkeit unter Einbeziehung künftiger Fertigungskapazitäten und Beschaffungen.
Teillieferung
Versand verfügbarer Teilmengen eines Auftrags vor Fertigstellung der Gesamtlieferung.
Dropshipping (Streckengeschäft)
Direktlieferung vom Vorlieferanten an den Endkunden ohne Zwischenlagerung.
Incoterms 2020
Internationale Handelsklauseln zur Festlegung von Transportkosten und Gefahrenübergang.
Invoicing-Trigger
Automatischer Anstoß der Rechnungsstellung nach Lieferscheinquittierung.
📥 Eingänge & Trigger (Inputs)
  • Angenommenes Angebot aus dem Quotes-Modul
  • E-Commerce-Bestellung über Shop-Konnektoren (Shopify, WooCommerce)
  • Manuelle Auftragserfassung durch den Vertriebsinnendienst
  • Elektronischer Datenaustausch (EDI / EDIFACT ORDERS)
📤 Ausgänge & Arbeitsergebnisse (Outputs)
  • Rechtsverbindliche Auftragsbestätigung (PDF) mit Lieferterminzusage
  • Lagerreservierungen für Vorratsartikel (ATP)
  • Fertigungsanforderungen für kundenindividuelle Baugruppen (MTO)
  • Liefer- und Kommissionieraufträge für die Versandlogistik
  • Fakturierungsaufträge für die Debitorenbuchhaltung
⚡ Kaskaden & Folgeprozesse (Cascades)
  • order_confirmed -> stock_reservation: Sofortige Bestandsreservierung im Lager
  • order_confirmed -> trigger_mto_assembly: Erzeugung von Fertigungsaufträgen bei MTO
  • order_shipped -> invoice_generation: Automatischer Rechnungsentwurf nach Warenausgang
  • credit_limit_exceeded -> lock_order: Kreditsperre und Benachrichtigung an Finance
🛡️ Nebenprozesse & Resilienz
  • Bonitäts- und Kreditlimitprüfung mit Ausnahmegenehmigung durch den CFO
  • Stornierung von Aufträgen mit automatischer Freigabe gebundener Bestände
  • Rückstandsbearbeitung und Lieferterminanpassung bei Lieferantenverzögerung
  • Zollprüfung und Sanktionslistenabgleich bei Exportkunden in Drittländer
💡 No-Code Checkliste & Praxistipps
  • Kreditlimits und Zahlungsziele kundenindividuell im Debitorenstamm hinterlegen
  • Lieferzeit-Puffer für die CTP-Terminierung im System definieren
  • Sperrgründe für Aufträge (z.B. ungeklärte Technik, Kreditsperre) parametrieren
  • No-Code Zusatzfelder für Kundenbestellnummer und Frachtführerhinweise anlegen

🗄️ Data Models & Fields

Keine dedizierten Tabellen für dieses Modul registriert.

🔌 Entry Points (UI & APIs)

Art Method Endpoint / Path Titel & Zweck Required Role
⚡ REST API GET /api/v1/ecommerce/channels
list_channels
Semantic binding: inventory_only; mutation=False
ecommerce
⚡ REST API GET /api/v1/ecommerce/webhooks/channels/{channel_id}
receive_channel_webhook_challenge
Semantic binding: inventory_only; mutation=False
ecommerce
⚡ REST API GET /ecommerce
ecommerce_page
Semantic binding: inventory_only; mutation=False
ecommerce
⚡ REST API GET /ecommerce/channels/{channel_id}/preview-order
preview_order_page
Semantic binding: inventory_only; mutation=False
ecommerce
⚡ REST API GET /ecommerce/channels/{channel_id}/settings
channel_settings_page
Semantic binding: inventory_only; mutation=False
ecommerce
⚡ REST API POST /api/v1/ecommerce/channels
create_channel
Semantic binding: operator_surface; mutation=True
ecommerce
⚡ REST API POST /api/v1/ecommerce/webhooks/channels/{channel_id}
receive_signed_channel_webhook
Semantic binding: operator_surface; mutation=True
ecommerce
⚡ REST API POST /api/v1/ecommerce/webhooks/{channel_slug}
receive_order_webhook
Semantic binding: operator_surface; mutation=True
ecommerce
⚡ REST API POST /ecommerce/channels
create_channel
Semantic binding: operator_surface; mutation=True
ecommerce
⚡ REST API POST /ecommerce/channels/{channel_id}/delete
delete_channel
Semantic binding: operator_surface; mutation=True
ecommerce
⚡ REST API POST /ecommerce/channels/{channel_id}/poll-orders
poll_channel_orders
Semantic binding: operator_surface; mutation=True
ecommerce
⚡ REST API POST /ecommerce/channels/{channel_id}/preview-order
preview_order_submission
Semantic binding: operator_surface; mutation=True
ecommerce
⚡ REST API POST /ecommerce/channels/{channel_id}/settings
update_channel_settings
Semantic binding: operator_surface; mutation=True
ecommerce
⚡ REST API POST /ecommerce/channels/{channel_id}/simulate-order
legacy_simulate_order
Semantic binding: operator_surface; mutation=True
ecommerce
⚡ REST API POST /ecommerce/channels/{channel_id}/toggle
toggle_channel
Semantic binding: operator_surface; mutation=True
ecommerce
⚡ REST API POST /ecommerce/order-syncs/{sync_id}/push-fulfillment
push_order_fulfillment
Semantic binding: operator_surface; mutation=True
ecommerce

🛡️ Regulatory & Compliance

Dieses Modul unterliegt folgenden gesetzlichen, regulatorischen und Revisionsstandards:

  • GoBD Nachvollziehbarkeit
  • Mandanten-Isolation (PostgreSQL RLS)