💶

Rechnungen & Gutschriften

invoices sales_billing 🛡️ RLS Protected

End-to-End-Vertriebsfluss: Kalkulation, Angebotsannahme, Projektumwandlung, Rechnungsstellung und Mahnwesen.

Fachliche Bestimmung: Zentrales Herzstück des Vertriebs und der Fakturierung. Angebote werden erfasst, kalkuliert und versendet. Bei Annahme kaskadiert das System automatisch in Projekt und Werkstattauftrag sowie Beschaffung (Strecke oder BTO). Rechnungen unterstützen gesetzliche Formate wie ZUGFeRD und XRechnung (PEPPOL) sowie Skontoverwaltung und SEPA-Zahlungsverkehr.

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

⚡ Workflows & Lifecycles

Quote-to-Cash Workflow-Kaskade `quote_to_cash_cascade`

Vom Angebot über Annahme, automatische Auftragskonvertierung, Teillieferung bis zur Schlussrechnung.

stateDiagram-v2 [*] --> DRAFT: Angebot anlegen DRAFT --> SENT: Versenden an Kunden SENT --> ACCEPTED: Kunde bestätigt Angebot ACCEPTED --> CONVERTED: convert_to_project() state CONVERTED { direction LR WorkOrder: Arbeitsauftrag Dropship: Streckenbestellung BTO: Einkaufslager } CONVERTED --> INVOICED: Rechnung erstellen (ZUGFeRD/DATEV) INVOICED --> PAID: Zahlungseingang (SEPA/Bank) PAID --> [*]

1. DRAFT

Entwurf

Erfassung von Positionen, Rabatten, Zahlungszielen und Lieferadressen.

Aktionen: Preise berechnen

2. SENT

Versendet

PDF-Generierung und Versand an Kunden per E-Mail oder Portal.

Aktionen: Gültigkeitsfrist überwachen

3. ACCEPTED

Angenommen

Kunde akzeptiert das Angebot (online oder im ERP).

Aktionen: convert_to_project ausführen

4. CONVERTED

Kaskadiert

Automatische Generierung von WorkOrder, Streckenbestellung oder Materialreservierung.

Aktionen: Lieferschein / Rechnung freischalten

5. INVOICED

Fakturiert

Erstellung der steuerkonformen Ausgangsrechnung (PDF/A-3, ZUGFeRD).

Aktionen: Buchungsstapel für DATEV erzeugen

Benutzerbefehl: billing agent `plan:command_billing_agent`

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

1. billing_agent

billing_agent

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

Aktionen: billing_agent

Benutzerbefehl: billing general agent `plan:command_billing_general_agent`

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

1. billing_general_agent

billing_general_agent

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

Aktionen: billing_general_agent

Benutzerbefehl: dunning agent `plan:command_dunning_agent`

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

1. dunning_agent

dunning_agent

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

Aktionen: dunning_agent

Rechnung versendet `plan:invoice_lifecycle`

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

1. payment_matching_agent

payment_matching_agent

{"key": "step_0", "label": "Zahlung zuordnen", "adapter": "agent.execute", "agent": "payment_matching_agent", "condition_fact": "payment_received"}

Aktionen: payment_matching_agent

2. dunning_agent

dunning_agent

{"key": "step_1", "label": "Mahnung vorbereiten", "adapter": "agent.execute", "agent": "dunning_agent", "condition_fact": "is_overdue"}

Aktionen: dunning_agent

Mehrarbeit `status:extra_work`

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

1. detected

detected

Status «detected» der Zustandsmaschine Mehrarbeit.

2. accepted

accepted

Status «accepted» der Zustandsmaschine Mehrarbeit.

3. rejected

rejected

Status «rejected» der Zustandsmaschine Mehrarbeit.

4. quoted

quoted

Status «quoted» der Zustandsmaschine Mehrarbeit.

5. invoiced

invoiced

Status «invoiced» der Zustandsmaschine Mehrarbeit.

Rechnung `status:invoice`

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

1. draft

draft

Status «draft» der Zustandsmaschine Rechnung.

2. proforma

proforma

Status «proforma» der Zustandsmaschine Rechnung.

3. issued

issued

Status «issued» der Zustandsmaschine Rechnung.

4. sent

sent

Status «sent» der Zustandsmaschine Rechnung.

5. partially_paid

partially_paid

Status «partially_paid» der Zustandsmaschine Rechnung.

6. paid

paid

Status «paid» der Zustandsmaschine Rechnung.

7. overdue

overdue

Status «overdue» der Zustandsmaschine Rechnung.

8. cancelled

cancelled

Status «cancelled» der Zustandsmaschine Rechnung.

Peppol-Übertragung `status:peppol_transmission`

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

1. draft

draft

Status «draft» der Zustandsmaschine Peppol-Übertragung.

2. queued

queued

Status «queued» der Zustandsmaschine Peppol-Übertragung.

3. transmitting

transmitting

Status «transmitting» der Zustandsmaschine Peppol-Übertragung.

4. delivered

delivered

Status «delivered» der Zustandsmaschine Peppol-Übertragung.

5. rejected

rejected

Status «rejected» der Zustandsmaschine Peppol-Übertragung.

6. failed

failed

Status «failed» der Zustandsmaschine Peppol-Übertragung.

⚙️ Fachprozesse & Capabilities (System-Fachlogik)

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

Gesamt: 31 manual_entry: 1 engine: 13 operator_surface: 2 engine_step: 8 durable_plan: 4 observable_only: 3

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
Rechnungsentwurf anlegen `capability:create_invoice_draft` Op: `create_invoice_draft`	Objekt: `invoice` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`invoice.draft_created`
Rechnung aus Angebot erstellen `capability:create_invoice_from_quote` Op: `create_invoice_from_quote`	Objekt: `quote` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`invoice.draft_created`
Rechnung aus Auftrag erstellen `capability:create_invoice_from_work_order` Op: `create_invoice_from_work_order`	Objekt: `work_order` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`invoice.draft_created`
Auftragsrechnung erstellen `capability:create_order_invoice` Op: `create_order_invoice`	Objekt: `work_order` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`invoice.draft_created`
Verkaufsrechnung aus Auftrag erzeugen `capability:create_sales_order_invoice` Op: `create_sales_order_invoice`	Objekt: `sales_order` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`invoice.created`
VOB-Kumulativrechnung erstellen `capability:create_vob_cumulative_invoice` Op: `create_vob_cumulative_invoice`	Objekt: `project` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`invoice.vob_created`
Rechnungsentwurf verwerfen `capability:delete_invoice_draft` Op: `delete_invoice_draft`	Objekt: `invoice` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`invoice.deleted`
Factor buchen `capability:invoice.factor.apply` Op: `invoice.factor.apply`	Objekt: `invoice` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`invoice.factor.apply`
Factor Warnung `capability:invoice.factor.warn` Op: `invoice.factor.warn`	Objekt: `invoice` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`invoice.factor.warn`
Rechnung ausstellen `capability:invoice.issue` Op: `invoice.issue`	Intent: `issue_invoice` Quelle: `code:capability_registry`	⚙️ Engine	🔒 Freigabe nötig Risiko: `external_effect`	`invoice.issued`
Ausgangsrechnung festschreiben `capability:issue_customer_invoice` Op: `issue_customer_invoice`	Objekt: `invoice` Quelle: `code:capability_registry`	⚙️ Engine	🔒 Freigabe nötig Risiko: `external_effect`	`invoice.issued`
Portal Rechnung `capability:portal.invoice.publish` Op: `portal.invoice.publish`	Objekt: `portal_invoice` Quelle: `code:capability_registry`	⚙️ Engine	🔒 Freigabe nötig Risiko: `external_effect`	`portal.invoice.publish`
Rechnungsentwurf bearbeiten `capability:update_invoice_draft` Op: `update_invoice_draft`	Objekt: `invoice` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`invoice.draft_updated`
invoice: create form `form_surface_anchor:invoice.create`	Objekt: `invoice` Quelle: `code:erp_form_surface`	operator_surface	✓ Auto	Keine Seiteneffekte deklariert
invoice: edit form `form_surface_anchor:invoice.edit`	Objekt: `invoice` Quelle: `code:erp_form_surface`	operator_surface	✓ Auto	Keine Seiteneffekte deklariert
create invoice draft `gateway:create_invoice_draft` Op: `create_invoice_draft`	create invoice draft Quelle: `code:engine_facade`	⚙️ Engine	✓ Auto	Keine Seiteneffekte deklariert
create invoice from quote `gateway:create_invoice_from_quote` Op: `create_invoice_from_quote`	create invoice from quote Quelle: `code:engine_facade`	⚙️ Engine	✓ Auto	Keine Seiteneffekte deklariert
create order invoice `gateway:create_order_invoice` Op: `create_order_invoice`	create order invoice Quelle: `code:engine_facade`	⚙️ Engine	✓ Auto	Keine Seiteneffekte deklariert
delete invoice draft `gateway:delete_invoice_draft` Op: `delete_invoice_draft`	delete invoice draft Quelle: `code:engine_facade`	⚙️ Engine	✓ Auto	Keine Seiteneffekte deklariert
invoice from work order `gateway:invoice_from_work_order` Op: `create_invoice_from_work_order`	invoice from work order Quelle: `code:engine_facade`	⚙️ Engine	✓ Auto	Keine Seiteneffekte deklariert
issue customer invoice `gateway:issue_customer_invoice` Op: `issue_customer_invoice`	issue customer invoice Quelle: `code:engine_facade`	⚙️ Engine	✓ Auto	Keine Seiteneffekte deklariert
register invoice payment `gateway:register_invoice_payment` Op: `register_invoice_payment`	register invoice payment Quelle: `code:engine_facade`	⚙️ Engine	✓ Auto	Keine Seiteneffekte deklariert
update invoice draft `gateway:update_invoice_draft` Op: `update_invoice_draft`	update invoice draft Quelle: `code:engine_facade`	⚙️ Engine	✓ Auto	Keine Seiteneffekte deklariert
Benutzerbefehl: billing agent `plan:command_billing_agent`	Benutzerbefehl: billing agent Quelle: `code:reviewed_execution_plan`	durable_plan	✓ Auto	Keine Seiteneffekte deklariert
Benutzerbefehl: billing general agent `plan:command_billing_general_agent`	Benutzerbefehl: billing general agent Quelle: `code:reviewed_execution_plan`	durable_plan	✓ Auto	Keine Seiteneffekte deklariert
Benutzerbefehl: dunning agent `plan:command_dunning_agent`	Benutzerbefehl: dunning agent Quelle: `code:reviewed_execution_plan`	durable_plan	✓ Auto	Keine Seiteneffekte deklariert
Rechnung versendet `plan:invoice_lifecycle`	Rechnung versendet Quelle: `code:reviewed_execution_plan`	durable_plan	✓ Auto	Keine Seiteneffekte deklariert
Mehrarbeit `status:extra_work`	Objekt: `extra_work` Quelle: `code:status_machine`	observable_only	✓ Auto	Keine Seiteneffekte deklariert
Rechnung `status:invoice`	Objekt: `invoice` Quelle: `code:status_machine`	observable_only	✓ Auto	Keine Seiteneffekte deklariert
Peppol-Übertragung `status:peppol_transmission`	Objekt: `peppol_transmission` 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 `invoices`

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.
de-ao-145-147, Abgabenordnung (AO) §§ 145–147, Ausgabe AO §§ 145–147, geltende Fassung (Stand 2026-10-25). Art: regulatory. Öffentlicher Text. Die Nennung ist keine Klauselprüfung. Kataloganforderungen: ao-record-keeping, ao-orderliness, ao-retention. Katalogstatus: NOT_ASSESSED.
en-16931-2017-a1-2019, EN 16931-1:2017+A1:2019 Electronic invoicing — Part 1: Semantic data model of the core elements of an electronic invoice, Ausgabe EN 16931-1:2017+A1:2019. Art: technical_interoperability. Lizenzierter Volltext liegt nicht vor. Keine Klauselprüfung. Kataloganforderungen: en16931-semantic-model. Katalogstatus: NOT_ASSESSED.
xrechnung-3.0.2, XRechnung 3.0.2, Ausgabe XRechnung 3.0.2 (gültig ab 2026-10-13; Vorversion 4.0.0 vom 2026-09-15 nicht produktiv). Art: technical_interoperability. Öffentlicher Text. Die Nennung ist keine Klauselprüfung. Kataloganforderungen: xrechnung-3.0.2/format. Katalogstatus: NOT_ASSESSED.
de-ustg-14, Umsatzsteuergesetz (UStG) § 14, Ausgabe UStG § 14, geltende Fassung (Stand 2026-10-25). Art: regulatory. Öffentlicher Text. Die Nennung ist keine Klauselprüfung. Kataloganforderungen: ustg-14-invoice-requirements. Katalogstatus: NOT_ASSESSED.

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

InvoiceItems invoice_items RLS Aktiv

34 Fields / Columns

Tabelle invoice_items

Feldname	Data Type	Required	Schlüssel	Functional Meaning
`invoice_id`	`UUID`	Ja *	FK ➔ invoices.id	Feld invoice_id
`position`	`INTEGER`	Ja *	-	Feld position
`line_type`	`VARCHAR(48)`	Ja *	-	Feld line_type
`product_id`	`UUID`	Nein	FK ➔ products.id	Feld product_id
`project_id`	`UUID`	Nein	FK ➔ projects.id	Feld project_id
`work_order_id`	`UUID`	Nein	FK ➔ work_orders.id	Feld work_order_id
`accounting_category_id`	`UUID`	Nein	FK ➔ accounting_categories.id	Feld accounting_category_id
`cost_type_id`	`UUID`	Nein	FK ➔ cost_types.id	Feld cost_type_id
`cost_center`	`VARCHAR(64)`	Nein	-	Feld cost_center
`cost_object`	`VARCHAR(64)`	Nein	-	Feld cost_object
`description`	`TEXT`	Ja *	-	Feld description
`quantity`	`NUMERIC(14, 4)`	Ja *	-	Feld quantity
`unit`	`VARCHAR(16)`	Ja *	-	Feld unit
`unit_price`	`NUMERIC(14, 2)`	Ja *	-	Feld unit_price
`discount_percent`	`NUMERIC(5, 2)`	Ja *	-	Feld discount_percent
`tax_rate`	`NUMERIC(6, 4)`	Ja *	-	Feld tax_rate
`tax_regime`	`VARCHAR(32)`	Ja *	-	Feld tax_regime
`purchase_price`	`NUMERIC(14, 2)`	Nein	-	Feld purchase_price
`margin_amount`	`NUMERIC(14, 2)`	Nein	-	Feld margin_amount
`margin_tax_amount`	`NUMERIC(14, 2)`	Nein	-	Feld margin_tax_amount
`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
`source_work_log_id`	`UUID`	Nein	FK ➔ work_logs.id	Feld source_work_log_id
`source_expense_item_id`	`UUID`	Nein	FK ➔ expense_items.id	Feld source_expense_item_id
`tracking_entries`	`JSONB`	Ja *	-	Feld tracking_entries
`deducted_invoice_id`	`UUID`	Nein	FK ➔ invoices.id	Feld deducted_invoice_id
`purchase_item_id`	`UUID`	Nein	FK ➔ purchase_items.id	Feld purchase_item_id
`source_invoice_item_id`	`UUID`	Nein	FK ➔ invoice_items.id	Feld source_invoice_item_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
`metadata`	`JSONB`	Ja *	-	Feld metadata

Invoices invoices RLS Aktiv

66 Fields / Columns

Tabelle invoices

Feldname	Data Type	Required	Schlüssel	Functional Meaning
`invoice_type`	`VARCHAR(48)`	Ja *	-	Feld invoice_type
`invoice_subtype`	`VARCHAR(48)`	Ja *	-	Feld invoice_subtype
`invoice_number`	`VARCHAR(64)`	Ja *	-	Feld invoice_number
`legal_entity_id`	`UUID`	Nein	FK ➔ legal_entities.id	Feld legal_entity_id
`customer_id`	`UUID`	Nein	FK ➔ customers.id	Feld customer_id
`bill_to_customer_id`	`UUID`	Nein	FK ➔ customers.id	Feld bill_to_customer_id
`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
`accounting_category_id`	`UUID`	Nein	FK ➔ accounting_categories.id	Feld accounting_category_id
`cost_type_id`	`UUID`	Nein	FK ➔ cost_types.id	Feld cost_type_id
`cost_center`	`VARCHAR(64)`	Nein	-	Feld cost_center
`cost_object`	`VARCHAR(64)`	Nein	-	Feld cost_object
`original_invoice_id`	`UUID`	Nein	FK ➔ invoices.id	Feld original_invoice_id
`quote_id`	`UUID`	Nein	FK ➔ quotes.id	Feld quote_id
`purchase_id`	`UUID`	Nein	FK ➔ purchases.id	Feld purchase_id
`goods_receipt_id`	`UUID`	Nein	FK ➔ goods_receipts.id	Feld goods_receipt_id
`contract_id`	`UUID`	Nein	-	Feld contract_id
`document_id`	`UUID`	Nein	FK ➔ documents.id	Feld document_id
`issue_date`	`DATE`	Nein	-	Feld issue_date
`due_date`	`DATE`	Nein	-	Feld due_date
`sent_at`	`DATETIME`	Nein	-	Feld sent_at
`payment_terms`	`VARCHAR(128)`	Nein	-	Feld payment_terms
`payment_term_code`	`VARCHAR(32)`	Nein	-	Feld payment_term_code
`notes`	`TEXT`	Nein	-	Feld notes
`reference`	`VARCHAR(128)`	Nein	-	Feld reference
`delivery_date`	`DATE`	Nein	-	Feld delivery_date
`currency`	`VARCHAR(3)`	Ja *	-	Feld currency
`subtotal`	`NUMERIC(14, 2)`	Ja *	-	Feld subtotal
`discount_total`	`NUMERIC(14, 2)`	Ja *	-	Feld discount_total
`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
`paid_amount`	`NUMERIC(14, 2)`	Ja *	-	Feld paid_amount
`residual_amount`	`NUMERIC(14, 2)`	Ja *	-	Feld residual_amount
`skonto_days`	`INTEGER`	Nein	-	Feld skonto_days
`skonto_percent`	`NUMERIC(5, 2)`	Nein	-	Feld skonto_percent
`skonto_date`	`DATE`	Nein	-	Feld skonto_date
`skonto_amount`	`NUMERIC(14, 2)`	Nein	-	Feld skonto_amount
`tax_breakdown`	`JSONB`	Nein	-	Feld tax_breakdown
`tax_exemption_reason`	`VARCHAR(255)`	Nein	-	Feld tax_exemption_reason
`dunning_level`	`INTEGER`	Ja *	-	Feld dunning_level
`dunning_date`	`DATE`	Nein	-	Feld dunning_date
`dunning_fee`	`NUMERIC(14, 2)`	Ja *	-	Feld dunning_fee
`bank_name`	`VARCHAR(255)`	Nein	-	Feld bank_name
`iban`	`VARCHAR(50)`	Nein	-	Feld iban
`bic`	`VARCHAR(20)`	Nein	-	Feld bic
`billing_mode`	`VARCHAR(48)`	Ja *	-	Feld billing_mode
`cumulative_sequence`	`INTEGER`	Nein	-	Feld cumulative_sequence
`previous_invoices_net`	`NUMERIC(14, 2)`	Ja *	-	Feld previous_invoices_net
`total_performance_net`	`NUMERIC(14, 2)`	Ja *	-	Feld total_performance_net
`retention_rate`	`NUMERIC(5, 2)`	Ja *	-	Feld retention_rate
`retention_amount`	`NUMERIC(14, 2)`	Ja *	-	Feld retention_amount
`measurement_id`	`UUID`	Nein	FK ➔ project_measurements.id	Feld measurement_id
`status`	`VARCHAR(48)`	Ja *	-	Feld status
`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/invoices/{invoice_id}`	delete_invoice Semantic binding: operator_surface; mutation=True	`invoices`
⚡ REST API	DELETE	`/api/v1/invoices/{invoice_id}/items/{item_id:uuid}`	delete_invoice_item Semantic binding: operator_surface; mutation=True	`invoices`
⚡ REST API	DELETE	`/api/v1/pricelists/{pricelist_id}/items/{item_id}`	delete_item Semantic binding: operator_surface; mutation=True	`invoices`
⚡ REST API	GET	`/api/v1/invoices`	list_invoices Semantic binding: inventory_only; mutation=False	`invoices`
⚡ REST API	GET	`/api/v1/invoices/{invoice_id}`	get_invoice Semantic binding: inventory_only; mutation=False	`invoices`
⚡ REST API	GET	`/api/v1/invoices/{invoice_id}/credit-remaining`	get_credit_remaining Semantic binding: inventory_only; mutation=False	`invoices`
⚡ REST API	GET	`/api/v1/invoices/{invoice_id}/delivery-note.pdf`	get_invoice_delivery_note Semantic binding: inventory_only; mutation=False	`invoices`
⚡ REST API	GET	`/api/v1/invoices/{invoice_id}/html`	get_invoice_html Semantic binding: inventory_only; mutation=False	`invoices`
⚡ REST API	GET	`/api/v1/invoices/{invoice_id}/payments`	list_invoice_payments Semantic binding: inventory_only; mutation=False	`invoices`
⚡ REST API	GET	`/api/v1/invoices/{invoice_id}/pdf`	get_invoice_pdf Semantic binding: inventory_only; mutation=False	`invoices`
⚡ REST API	GET	`/api/v1/invoices/{invoice_id}/zugferd-xml`	get_zugferd_xml Semantic binding: inventory_only; mutation=False	`invoices`
⚡ REST API	GET	`/api/v1/peppol/invoices/{invoice_id}/ubl`	get_invoice_peppol_ubl Semantic binding: inventory_only; mutation=False	`invoices`
⚡ REST API	GET	`/api/v1/peppol/lookup`	lookup_peppol_recipient Semantic binding: inventory_only; mutation=False	`invoices`
⚡ REST API	GET	`/api/v1/peppol/schemes`	list_peppol_schemes Semantic binding: inventory_only; mutation=False	`invoices`
⚡ REST API	GET	`/api/v1/peppol/transmissions`	list_peppol_transmissions Semantic binding: inventory_only; mutation=False	`invoices`
⚡ REST API	GET	`/api/v1/peppol/transmissions/{transmission_id}`	get_peppol_transmission Semantic binding: inventory_only; mutation=False	`invoices`
⚡ REST API	GET	`/api/v1/pricelists`	list_pricelists Semantic binding: inventory_only; mutation=False	`invoices`
⚡ REST API	GET	`/api/v1/pricelists/{pricelist_id}/items`	list_items Semantic binding: inventory_only; mutation=False	`invoices`
⚡ REST API	GET	`/api/v1/pricelists/{pricelist_id}/resolve`	resolve_price Semantic binding: inventory_only; mutation=False	`invoices`
⚡ REST API	GET	`/invoices`	invoices_page Semantic binding: inventory_only; mutation=False	`invoices`
⚡ REST API	GET	`/invoices/new`	invoice_create_page Semantic binding: inventory_only; mutation=False	`invoices`
⚡ REST API	GET	`/invoices/{invoice_id}`	invoice_detail_page Semantic binding: inventory_only; mutation=False	`invoices`
⚡ REST API	GET	`/portal/{slug}/rechnungen`	invoices_page Semantic binding: inventory_only; mutation=False	`invoices`
⚡ REST API	GET	`/portal/{slug}/rechnungen/{invoice_id}/pdf`	invoice_pdf_download Semantic binding: inventory_only; mutation=False	`invoices`
⚡ REST API	GET	`/pricelists`	pricelists_page Semantic binding: inventory_only; mutation=False	`invoices`
⚡ REST API	GET	`/pricelists/new`	pricelists_new_page Semantic binding: inventory_only; mutation=False	`invoices`
⚡ REST API	GET	`/pricelists/{pricelist_id}/edit`	pricelists_edit_page Semantic binding: inventory_only; mutation=False	`invoices`
⚡ REST API	PATCH	`/api/v1/invoices/{invoice_id}`	update_invoice Semantic binding: operator_surface; mutation=True	`invoices`
⚡ REST API	PATCH	`/api/v1/invoices/{invoice_id}/items/reorder`	reorder_invoice_items Semantic binding: operator_surface; mutation=True	`invoices`
⚡ REST API	PATCH	`/api/v1/invoices/{invoice_id}/items/{item_id:uuid}`	update_invoice_item Semantic binding: operator_surface; mutation=True	`invoices`
⚡ REST API	PATCH	`/api/v1/pricelists/{pricelist_id}`	update_pricelist Semantic binding: operator_surface; mutation=True	`invoices`
⚡ REST API	POST	`/api/v1/invoices`	create_invoice Semantic binding: operator_surface; mutation=True	`invoices`
⚡ REST API	POST	`/api/v1/invoices/collective-credit-note`	create_collective_credit_note Semantic binding: operator_surface; mutation=True	`invoices`
⚡ REST API	POST	`/api/v1/invoices/final-from-partials`	create_final_invoice_from_partials Semantic binding: operator_surface; mutation=True	`invoices`
⚡ REST API	POST	`/api/v1/invoices/from-work-order/{work_order_id}`	create_invoice_from_work_order Semantic binding: operator_surface; mutation=True	`invoices`
⚡ REST API	POST	`/api/v1/invoices/{invoice_id}/convert-final`	convert_to_final_invoice Semantic binding: operator_surface; mutation=True	`invoices`
⚡ REST API	POST	`/api/v1/invoices/{invoice_id}/convert-proforma`	convert_to_proforma Semantic binding: operator_surface; mutation=True	`invoices`
⚡ REST API	POST	`/api/v1/invoices/{invoice_id}/credit-note`	create_credit_note Semantic binding: operator_surface; mutation=True	`invoices`
⚡ REST API	POST	`/api/v1/invoices/{invoice_id}/dunning`	escalate_invoice_dunning Semantic binding: operator_surface; mutation=True	`invoices`
⚡ REST API	POST	`/api/v1/invoices/{invoice_id}/escalate-ticket`	escalate_invoice_to_ticket Semantic binding: operator_surface; mutation=True	`invoices`
⚡ REST API	POST	`/api/v1/invoices/{invoice_id}/issue`	issue_invoice Semantic binding: operator_surface; mutation=True	`invoices`
⚡ REST API	POST	`/api/v1/invoices/{invoice_id}/items`	add_invoice_item Semantic binding: operator_surface; mutation=True	`invoices`
⚡ REST API	POST	`/api/v1/invoices/{invoice_id}/partial-credit-note`	create_partial_credit_note Semantic binding: operator_surface; mutation=True	`invoices`
⚡ REST API	POST	`/api/v1/invoices/{invoice_id}/payments`	register_invoice_payment Semantic binding: operator_surface; mutation=True	`invoices`
⚡ REST API	POST	`/api/v1/invoices/{invoice_id}/send`	send_invoice Semantic binding: operator_surface; mutation=True	`invoices`
⚡ REST API	POST	`/api/v1/invoices/{invoice_id}/stock-issue`	create_invoice_stock_issue Semantic binding: operator_surface; mutation=True	`invoices`
⚡ REST API	POST	`/api/v1/peppol/invoices/{invoice_id}/transmit`	transmit_invoice_via_peppol Semantic binding: operator_surface; mutation=True	`invoices`
⚡ REST API	POST	`/api/v1/pricelists`	create_pricelist Semantic binding: operator_surface; mutation=True	`invoices`
⚡ REST API	POST	`/api/v1/pricelists/{pricelist_id}/items`	add_item Semantic binding: operator_surface; mutation=True	`invoices`
⚡ REST API	POST	`/portal/{slug}/rechnungen/{invoice_id}/gutschrift-anfordern`	credit_note_request Semantic binding: operator_surface; mutation=True	`invoices`
🖥️ WEB-UI	GET	`/quotes`	Angebotsübersicht Liste aller Angebote mit Statusfilter und Strecken-Badge	`quotes:read`
⚡ REST API	POST	`/api/v1/quotes/{id}/convert-to-workorder`	Auftragsumwandlung Kaskadiert angenommenes Angebot in Projekt & WorkOrder	`quotes:write`

🛡️ Regulatory & Compliance

Dieses Modul unterliegt folgenden gesetzlichen, regulatorischen und Revisionsstandards:

GoBD (Fortlaufende Nummerierung, Unveränderbarkeit)
UStG §14 (Pflichtangaben auf Rechnungen)
ZUGFeRD 2.2 / XRechnung (PEPPOL)

Related Modules:

➔ dropship ➔ customers ➔ workorders ➔ purchasing ➔ accounting

Rechnungen & Gutschriften

⚡ Workflows & Lifecycles

Quote-to-Cash Workflow-Kaskade quote_to_cash_cascade

Benutzerbefehl: billing agent plan:command_billing_agent

Benutzerbefehl: billing general agent plan:command_billing_general_agent

Benutzerbefehl: dunning agent plan:command_dunning_agent

Rechnung versendet plan:invoice_lifecycle

Mehrarbeit status:extra_work

Rechnung status:invoice

Peppol-Übertragung status:peppol_transmission

⚙️ 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 invoices

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

Quote-to-Cash Workflow-Kaskade `quote_to_cash_cascade`

Benutzerbefehl: billing agent `plan:command_billing_agent`

Benutzerbefehl: billing general agent `plan:command_billing_general_agent`

Benutzerbefehl: dunning agent `plan:command_dunning_agent`

Rechnung versendet `plan:invoice_lifecycle`

Mehrarbeit `status:extra_work`

Rechnung `status:invoice`

Peppol-Übertragung `status:peppol_transmission`

Normbezug für `invoices`

3. Der Gateway `gw:invoice_finalization@v1`