📘

Ausgaben & Spesen

expenses sales_billing 🛡️ RLS Protected

Ausgaben & Spesen — 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 (5) Fachprozesse & Capabilities (26) Data Models & Fields (2) Entry Points (UI & APIs) (14) Regulatory & Compliance

⚡ Workflows & Lifecycles

Benutzerbefehl: expense agent `plan:command_expense_agent`

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

1. expense_agent

expense_agent

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

Aktionen: expense_agent

Benutzerbefehl: expense general agent `plan:command_expense_general_agent`

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

1. expense_general_agent

expense_general_agent

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

Aktionen: expense_general_agent

Benutzerbefehl: receipt agent `plan:command_receipt_agent`

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

1. receipt_agent

receipt_agent

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

Aktionen: receipt_agent

Benutzerbefehl: supplier invoice agent `plan:command_supplier_invoice_agent`

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

1. supplier_invoice_agent

supplier_invoice_agent

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

Aktionen: supplier_invoice_agent

Ausgabe `status:expense`

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

1. detected

detected

Status «detected» der Zustandsmaschine Ausgabe.

2. needs_review

needs_review

Status «needs_review» der Zustandsmaschine Ausgabe.

3. approved

approved

Status «approved» der Zustandsmaschine Ausgabe.

4. exported

exported

Status «exported» der Zustandsmaschine Ausgabe.

⚙️ Fachprozesse & Capabilities (System-Fachlogik)

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

Gesamt: 26 manual_entry: 1 engine: 15 operator_surface: 1 engine_step: 4 durable_plan: 4 observable_only: 1

Capability & Schlüssel	Fachliche Bezeichnung	Ausführung / Coverage	Risikostufe & Freigabe	Effekte & Kaskaden
Agent-Einstieg expense_general_agent `agent_entry:expense_general_agent`	Agent-Einstieg expense_general_agent Quelle: `code:module_agent_map`	manual_entry	✓ Auto	Keine Seiteneffekte deklariert
Ausgabe freigeben `capability:approve_expense` Op: `approve_expense`	Objekt: `expense` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`expense.approved`
Ausgabe / Spesenbeleg erfassen `capability:create_expense_record` Op: `create_expense_record`	Objekt: `expense` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`expense.created`
Ausgabe löschen `capability:delete_expense_record` Op: `delete_expense_record`	Objekt: `expense` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`expense.deleted`
Ausgabe genehmigen `capability:expense.approve` Op: `expense.approve`	Intent: `approve_expense` Quelle: `code:capability_registry`	⚙️ Engine	🔒 Freigabe nötig Risiko: `business_record`	`expense.approved`
Ausgabe erfassen `capability:expense.create` Op: `expense.create`	Intent: `create_expense` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`expense.recorded`
Spesenrichtlinie `capability:expense.policy.check` Op: `expense.policy.check`	Objekt: `expense` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`expense.policy.check`
Spesen erstatten `capability:expense.reimburse` Op: `expense.reimburse`	Objekt: `expense` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`expense.reimburse`
Expense: add item `capability:finance.expense.add_item` Op: `finance.expense.add_item`	Objekt: `expense` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`expense.add_item`
Expense: approve `capability:finance.expense.approve` Op: `finance.expense.approve`	Objekt: `expense` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`expense.approve`
Expense: assign project `capability:finance.expense.assign_project` Op: `finance.expense.assign_project`	Objekt: `expense` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`expense.assign_project`
Expense: create `capability:finance.expense.create` Op: `finance.expense.create`	Objekt: `expense` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`expense.create`
Expense: delete `capability:finance.expense.delete` Op: `finance.expense.delete`	Objekt: `expense` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`expense.delete`
Expense: post to ledger `capability:finance.expense.post_to_ledger` Op: `finance.expense.post_to_ledger`	Objekt: `expense` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`expense.post_to_ledger`
Expense: update `capability:finance.expense.update` Op: `finance.expense.update`	Objekt: `expense` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`expense.update`
Ausgabe bearbeiten `capability:update_expense_record` Op: `update_expense_record`	Objekt: `expense` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`expense.updated`
expense: edit form `form_surface_anchor:expense.edit`	Objekt: `expense` Quelle: `code:erp_form_surface`	operator_surface	✓ Auto	Keine Seiteneffekte deklariert
approve expense `gateway:approve_expense` Op: `approve_expense`	approve expense Quelle: `code:engine_facade`	⚙️ Engine	✓ Auto	Keine Seiteneffekte deklariert
create expense record `gateway:create_expense_record` Op: `create_expense_record`	create expense record Quelle: `code:engine_facade`	⚙️ Engine	✓ Auto	Keine Seiteneffekte deklariert
delete expense record `gateway:delete_expense_record` Op: `delete_expense_record`	delete expense record Quelle: `code:engine_facade`	⚙️ Engine	✓ Auto	Keine Seiteneffekte deklariert
update expense record `gateway:update_expense_record` Op: `update_expense_record`	update expense record Quelle: `code:engine_facade`	⚙️ Engine	✓ Auto	Keine Seiteneffekte deklariert
Benutzerbefehl: expense agent `plan:command_expense_agent`	Benutzerbefehl: expense agent Quelle: `code:reviewed_execution_plan`	durable_plan	✓ Auto	Keine Seiteneffekte deklariert
Benutzerbefehl: expense general agent `plan:command_expense_general_agent`	Benutzerbefehl: expense general agent Quelle: `code:reviewed_execution_plan`	durable_plan	✓ Auto	Keine Seiteneffekte deklariert
Benutzerbefehl: receipt agent `plan:command_receipt_agent`	Benutzerbefehl: receipt agent Quelle: `code:reviewed_execution_plan`	durable_plan	✓ Auto	Keine Seiteneffekte deklariert
Benutzerbefehl: supplier invoice agent `plan:command_supplier_invoice_agent`	Benutzerbefehl: supplier invoice agent Quelle: `code:reviewed_execution_plan`	durable_plan	✓ Auto	Keine Seiteneffekte deklariert
Ausgabe `status:expense`	Objekt: `expense` 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 `expenses`

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. Kataloganforderungen: gobd-traceability, gobd-immutability, gobd-procedure-documentation, gobd-data-access. Katalogstatus: NOT_ASSESSED.

Im Auditauftrag zusätzlich genannt und nicht im Prüfkatalog v2026.10.1: ISO 37301. 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

ExpenseItems expense_items RLS Aktiv

20 Fields / Columns

Tabelle expense_items

Feldname	Data Type	Required	Schlüssel	Functional Meaning
`expense_id`	`UUID`	Ja *	FK ➔ expenses.id	Feld expense_id
`position`	`INTEGER`	Ja *	-	Feld position
`description`	`TEXT`	Ja *	-	Feld description
`product_id`	`UUID`	Nein	FK ➔ products.id	Feld product_id
`quantity`	`NUMERIC(14, 4)`	Nein	-	Feld quantity
`unit`	`VARCHAR(16)`	Nein	-	Feld unit
`unit_price`	`NUMERIC(14, 2)`	Nein	-	Feld unit_price
`net_amount`	`NUMERIC(14, 2)`	Ja *	-	Feld net_amount
`tax_rate`	`NUMERIC(6, 4)`	Ja *	-	Feld tax_rate
`tax_amount`	`NUMERIC(14, 2)`	Ja *	-	Feld tax_amount
`gross_amount`	`NUMERIC(14, 2)`	Ja *	-	Feld gross_amount
`project_id`	`UUID`	Nein	FK ➔ projects.id	Feld project_id
`material_action`	`VARCHAR(48)`	Ja *	-	Feld material_action
`inventory_action`	`VARCHAR(48)`	Ja *	-	Feld inventory_action
`confidence`	`NUMERIC(4, 3)`	Nein	-	Feld confidence
`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
`metadata`	`JSONB`	Ja *	-	Feld metadata

Expenses expenses RLS Aktiv

31 Fields / Columns

Tabelle expenses

Feldname	Data Type	Required	Schlüssel	Functional Meaning
`supplier_id`	`UUID`	Nein	FK ➔ suppliers.id	Feld supplier_id
`project_id`	`UUID`	Nein	FK ➔ projects.id	Feld project_id
`work_order_id`	`UUID`	Nein	FK ➔ work_orders.id	Feld work_order_id
`purchase_id`	`UUID`	Nein	FK ➔ purchases.id	Feld purchase_id
`goods_receipt_id`	`UUID`	Nein	FK ➔ goods_receipts.id	Feld goods_receipt_id
`document_id`	`UUID`	Nein	FK ➔ documents.id	Feld document_id
`expense_date`	`DATE`	Ja *	-	Feld expense_date
`receipt_number`	`VARCHAR(64)`	Nein	-	Feld receipt_number
`currency`	`VARCHAR(3)`	Ja *	-	Feld currency
`net_amount`	`NUMERIC(14, 2)`	Ja *	-	Feld net_amount
`tax_amount`	`NUMERIC(14, 2)`	Ja *	-	Feld tax_amount
`gross_amount`	`NUMERIC(14, 2)`	Ja *	-	Feld gross_amount
`payment_method`	`VARCHAR(32)`	Nein	-	Feld payment_method
`category`	`VARCHAR(64)`	Nein	-	Feld category
`cost_type_id`	`UUID`	Nein	FK ➔ cost_types.id	Feld cost_type_id
`cost_center_id`	`UUID`	Nein	FK ➔ cost_centers.id	Feld cost_center_id
`internal_order_id`	`UUID`	Nein	FK ➔ controlling_internal_orders.id	Feld internal_order_id
`status`	`VARCHAR(48)`	Ja *	-	Feld status
`confidence`	`NUMERIC(4, 3)`	Nein	-	Feld confidence
`totals_consistent`	`BOOLEAN`	Nein	-	Feld totals_consistent
`external_accounting_id`	`VARCHAR(128)`	Nein	-	Feld external_accounting_id
`idempotency_key`	`VARCHAR(128)`	Nein	-	Feld idempotency_key
`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
`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/expenses/{expense_id}`	delete_expense Semantic binding: operator_surface; mutation=True	`expenses`
⚡ REST API	GET	`/api/v1/expenses`	list_expenses Semantic binding: inventory_only; mutation=False	`expenses`
⚡ REST API	GET	`/api/v1/expenses/{expense_id}`	get_expense Semantic binding: inventory_only; mutation=False	`expenses`
⚡ REST API	GET	`/api/v1/expenses/{expense_id}/3way-match`	verify_3way_matching Semantic binding: inventory_only; mutation=False	`expenses`
⚡ REST API	GET	`/expenses`	expenses_page Semantic binding: inventory_only; mutation=False	`expenses`
⚡ REST API	GET	`/expenses/new`	expense_create_page Semantic binding: inventory_only; mutation=False	`expenses`
⚡ REST API	GET	`/expenses/{expense_id}`	expense_detail_page Semantic binding: inventory_only; mutation=False	`expenses`
⚡ REST API	PATCH	`/api/v1/expenses/{expense_id}`	update_expense Semantic binding: operator_surface; mutation=True	`expenses`
⚡ REST API	POST	`/api/v1/expenses`	create_expense Semantic binding: operator_surface; mutation=True	`expenses`
⚡ REST API	POST	`/api/v1/expenses/batch-approve`	batch_approve_expenses Semantic binding: operator_surface; mutation=True	`expenses`
⚡ REST API	POST	`/api/v1/expenses/upload`	upload_receipt Semantic binding: operator_surface; mutation=True	`expenses`
⚡ REST API	POST	`/api/v1/expenses/{expense_id}/approve`	approve_expense Semantic binding: operator_surface; mutation=True	`expenses`
⚡ REST API	POST	`/api/v1/expenses/{expense_id}/assign-project`	assign_project Semantic binding: operator_surface; mutation=True	`expenses`
⚡ REST API	POST	`/api/v1/expenses/{expense_id}/items`	add_expense_item Semantic binding: operator_surface; mutation=True	`expenses`

🛡️ Regulatory & Compliance

Dieses Modul unterliegt folgenden gesetzlichen, regulatorischen und Revisionsstandards:

GoBD Nachvollziehbarkeit
Mandanten-Isolation (PostgreSQL RLS)

Ausgaben & Spesen

⚡ Workflows & Lifecycles

Benutzerbefehl: expense agent plan:command_expense_agent

Benutzerbefehl: expense general agent plan:command_expense_general_agent

Benutzerbefehl: receipt agent plan:command_receipt_agent

Benutzerbefehl: supplier invoice agent plan:command_supplier_invoice_agent

Ausgabe status:expense

⚙️ Fachprozesse & Capabilities (System-Fachlogik)

🧠 Fachprozess-Erzählung & Dual Knowledge Architektur

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

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

1. Rechnungserstellung & Belegursprung (Billing Trigger)

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

3. Festschreibung nach GoBD (Immutability & Final Lock)

4. Versand & Bereitstellung (Multi-Channel Dispatch)

5. Zahlungsabgleich & Elektronischer Kontoauszug (Bank Reconciliation)

6. Mehrstufiges Mahnwesen (Dunning Run)

7. Hauptbuch, Kontenrahmen & DATEV-Export

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

Meta-Fachlogik: Die ideologische Blaupause & das normative Weltbild

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

2. Umsatzsteuerrecht & E-Rechnungs-Standards

3. Invarianten des Soll-Modells

Normbezug für expenses

Systemische Fachlogik: Faktische Umsetzung in Centurio ERP & Capabilities

Systemische Fachlogik: Die faktische Umsetzung in Centurio ERP

1. Datenmodelle & Semantische Schicht (ORM)

2. Das Capability-Register

3. Der Gateway gw:invoice_finalization@v1

4. Statusmodelle

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

KI-Consultant Blueprint: Customizing & No-Code Architektur

1. Kundenanforderungsanalyse

2. No-Code Zusatzfelder (Custom Fields)

3. No-Code Workflow Canvas DAGs

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

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

📚 Operative Prozessbegriffe & Transaktionsschnittstellen

🗄️ Data Models & Fields

🔌 Entry Points (UI & APIs)

🛡️ Regulatory & Compliance

Benutzerbefehl: expense agent `plan:command_expense_agent`

Benutzerbefehl: expense general agent `plan:command_expense_general_agent`

Benutzerbefehl: receipt agent `plan:command_receipt_agent`

Benutzerbefehl: supplier invoice agent `plan:command_supplier_invoice_agent`

Ausgabe `status:expense`

Normbezug für `expenses`

3. Der Gateway `gw:invoice_finalization@v1`