Centurio System- & Moduldokumentation
🔍
🏛️ Plattform-Architektur
🇩🇪 Deutsch 🇬🇧 English 🇫🇷 Français 🇪🇸 Español 🇮🇹 Italiano 🇳🇱 Nederlands 🇵🇱 Polski 🇵🇹 Português 🇨🇿 Čeština 🇸🇰 Slovenčina 🇭🇺 Magyar 🇷🇴 Română 🇧🇬 Български 🇬🇷 Ελληνικά 🇩🇰 Dansk 🇫🇮 Suomi 🇸🇪 Svenska 🇱🇹 Lietuvių 🇱🇻 Latviešu 🇪🇪 Eesti 🇭🇷 Hrvatski 🇸🇮 Slovenščina 🇲🇹 Malti 🇮🇪 Gaeilge 🇷🇺 Русский 🇺🇦 Українська 🇹🇷 Türkçe 🇳🇴 Norsk bokmål 🇷🇸 Српски 🇮🇸 Íslenska 🇨🇭 Schwiiz/Suisse
🔑 Login
Alle Module / sales_billing / Angebote, Rechnungen & Debitoren (Finance)
💶

Angebote, Rechnungen & Debitoren (Finance)

finance 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 & Lebenszyklen (8) Fachprozesse & Capabilities (31) Datenmodelle & Felder (2) Einstiegspunkte (UI & APIs) (52) Regulatorik & Compliance

⚡ Workflows & Lebenszyklen

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

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

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:

  1. Plausibilitätsprüfung: Prüft USt-IdNr., Steuersätze, Pflichtfelder nach § 14 UStG und rechnerische Summenintegrität.
  2. Festschreibung: Setzt Invoice.is_locked = true und Invoice.status = 'finalized'.
  3. Journalbuchung: Erzeugt atomar die Soll- und Haben-Zeilen in GeneralLedgerEntry.
  4. OP-Anlage: Bucht den offenen Posten in OpenItem.
  5. 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

🗄️ Datenmodelle & Felder

InvoiceItems invoice_items RLS Aktiv
34 Felder / Spalten

Tabelle invoice_items

Feldname Datentyp Pflicht Schlüssel Fachliche Bedeutung
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 Felder / Spalten

Tabelle invoices

Feldname Datentyp Pflicht Schlüssel Fachliche Bedeutung
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

🔌 Einstiegspunkte (UI & APIs)

Art Methode Endpunkt / Pfad Titel & Zweck Berechtigung
⚡ 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

🛡️ Regulatorik & Compliance

Dieses Modul unterliegt folgenden gesetzlichen, regulatorischen und Revisionsstandards:

  • GoBD (Fortlaufende Nummerierung, Unveränderbarkeit)
  • UStG §14 (Pflichtangaben auf Rechnungen)
  • ZUGFeRD 2.2 / XRechnung (PEPPOL)
Verknüpfte Module:
➔ dropship ➔ customers ➔ workorders ➔ purchasing ➔ accounting