Konten-Buchungen (Account Entries)

Diese Seite dokumentiert die FE-Route `/account-entries` (FE-Page-Komponente `AccountEntryMainListPage`) auf Übersichts-Ebene. Felder-Tabelle, Workflow-Beispiele und Stolpersteine sind **noch zu ergänzen** — Detail-Audit gegen FE-Seite + BE-Router (`accountEntry.router.ts`) ausstehend.

Zweck

Die Seite zeigt eine globale Übersicht aller Konten-Buchungen (AccountEntry-Datensätze) über alle Konten und Buchhaltungen Ihres Mandanten hinweg. Im Unterschied zu konten- oder buchhaltungs-spezifischen Listen liegt hier der Fokus auf der gesamten Buchungs-Historie.

Detail-Workflows (einzelne Konto-Buchungen oder monatlich aggregierte Listen) finden Sie unter:

• Konten — pro Konto
• Konto-Buchungen pro Konto — Sub-Route /accounts/:id/entries
• Buchhaltungen — pro Mandant
• Buchhaltungs-Monate — Monats-Snapshots

Voraussetzungen

- Mandant hat Buchhaltung aktiviert. - Mindestens eine Buchhaltung mit zugeordneten Konten existiert. - Berechtigungen `view:FE_Account` + `view:AccountEntry`.

Berechtigungen (CASL)

Frontend-Page-Guard (requiredAbility):

Action	Subject	Wirkung
view	FE_Account	Konten-Bereich zugänglich
view	AccountEntry	Buchungs-Liste sichtbar

API-CASL (BE):

Action	Subject
view	AccountEntry
create	AccountEntry
update	AccountEntry
delete	AccountEntry

Entstehung der Einträge

AccountEntry-Datensätze werden in zwei Wegen erzeugt:

1. Automatisch über den Booking-Service: Beim Buchen einer TransactionAllocation erzeugt bookAllocation() symmetrische Paare (Bank ↔ Debitor/Kreditor + GL-Buchung + Vorsteuer-Split). Skonto wird bei isSkonto = true automatisch auf Konto 8736 gebucht.
2. Manuell: Direkt-Buchungen in der Account-Detail-Sicht (POST /api/account-entries) — z. B. Eröffnungsbilanz-Buchungen, Korrekturen durch die Buchhaltungs-Leitung.

Description-Format (Welle 129)

Die description einer automatisch erzeugten Buchung folgt seitdem dieser Reihenfolge:

1. allocation.note — wenn der User beim Anlegen eine Notiz hinterlegt hat
2. <fromAccount.displayName> — <tx.reference> — Default, z. B. „Pleo – Andreas Hey — OBI SAGT DANKE"
3. Direct allocation <uuid> — Fallback (sollte selten auftreten)

Damit ist in der Kontoliste sofort erkennbar, woher eine Buchung stammt — kein UUID-Wirrwarr mehr.

RefLinks zu Transaktion und Allocation

Pro AccountEntry mit parentType = TransactionAllocation ist in der UI ein RefLink zum Quell-Datensatz vorhanden — Klick öffnet entweder die Allocation oder direkt die Transaktion im neuen Tab.

DATEV-Import (seit Juni 2026)

Ein DATEV-Kontenblatt (CSV) lässt sich importieren, um Bestandsbuchungen aus der bisherigen Buchhaltung zu übernehmen:

1. Vorschau (POST /account-entries/import-datev/preview, create:AccountEntry) — analysiert die CSV und zeigt, was angelegt würde: die Buchungen, neu anzulegende Stammdaten (Lieferanten/Kunden) und erkannte Buchungsmuster — ohne zu schreiben.
2. Übernehmen (POST /account-entries/import-datev/apply, create:AccountEntry) — legt die Buchungen, Stammdaten und Muster tatsächlich an.

So lässt sich der Konten-Bestand mit einem Schritt aus DATEV übernehmen; die gelernten Buchungsmuster boosten danach direkt die KI-Vorschläge im Cockpit.

DATEV-Abgleich (read-only, seit Juni 2026)

Ergänzend zum Import gibt es einen read-only DATEV-Abgleich (POST /account-entries/reconcile-datev, multipart-Upload eines DATEV-Kontenblatts). Er schreibt nichts, sondern vergleicht die DATEV-Buchungen Zeile für Zeile gegen die vorhandenen SpeamCore-Konten-Buchungen und liefert einen Abgleich-Report.

Das Matching arbeitet verbrauchend über Konto + Datum + Betrag (Beleg-Text in der description als Tie-Breaker). Je DATEV-Zeile entsteht ein Status:

Status	Bedeutung
Match	Buchung in DATEV und SpeamCore identisch gefunden.
Betrag weicht ab	gleiches Konto/Datum, aber abweichender Betrag.
Fehlt in SpeamCore	DATEV-Buchung ohne Gegenstück in SpeamCore.
Nur in SpeamCore	SpeamCore-Buchung ohne Gegenstück in DATEV.

So prüfen Sie, ob SpeamCore und die DATEV-Buchhaltung deckungsgleich sind — ohne Bestandsbuchungen zu verändern (Unterschied zum Import oben, der Buchungen anlegt).

Reverse-Charge-Buchungen (§13b UStG)

Wird eine Eingangsrechnung auf ein als §13b markiertes Aufwandskonto gebucht (Konto-Feld reverseChargeType = foreign_service, siehe Konten), erzeugt der Booking-Service zusätzlich die gegenläufigen Steuerbuchungen auf den Konten 1577 (abziehbare Vorsteuer §13b) und 1787 (Umsatzsteuer §13b). Beide heben sich auf — als Verbindlichkeit gegenüber dem Lieferanten bleibt nur der Nettobetrag stehen.

Verwandte Doku

• Buchhaltungskonten — Konzept
• KI-Allocation-Engine — wie Allocations das Booking auslösen
• Transaktions-Zuordnungen — Allocation-Modell
• Konten-Stammdaten — Anwender-Anleitung
• Banking zuordnen

Versionshinweise

• 2026-06-11: DATEV-Abgleich (read-only, /account-entries/reconcile-datev) und Reverse-Charge-Buchungen (§13b, Konten 1577/1787) ergänzt. Verifiziert an datevReconciliation.service.ts, accountEntry.router.ts und der §13b-Seed-Migration.
• 2026-06-09: DATEV-Import (/account-entries/import-datev/preview + /apply) ergänzt — DATEV-Kontenblatt-CSV: Vorschau (Buchungen + Stammdaten + Buchungsmuster, ohne Schreiben) und Übernehmen. Verifiziert an accountEntry.router.ts, datevBookingImport.service.ts.
• 2026-05-16 (Welle 129): description-Format der vom Booking-Service erzeugten Einträge umgestellt auf lesbares <fromAccount.displayName> — <tx.reference> (vorher UUID); RefLink-Section ergänzt.
• 2026-05-05: Stub-Doku — Felder-Tabelle aus AccountEntry-Modell + Workflow-Beispiele weiterhin offen für nächsten Audit-Pass.