Geführter Wechsel

Migration zu LedgerLou

Wir empfehlen, die Migration agent-geführt über Claude, ChatGPT oder einen anderen MCP-fähigen Agenten durchzuführen. Starte mit einem klaren Migrationsstichtag: Ab diesem Tag ist LedgerLou das operative Hauptbuch; alles davor wird im alten System abgeschlossen und über die Eröffnungsbilanzwerte übernommen.

Hilf mir bei der Migration zu LedgerLou.

Bitte starte den LedgerLou MCP-Wizard mit migration(action="start") und begleite mich Schritt für Schritt.
Frage zuerst nach Quellsystem, Migrationsstichtag, Bankkonten, Eröffnungsbilanzwerten und offenen Posten.
Prüfe danach mit migration(action="analyze"), was im Tenant noch fehlt, und schlage mir die nächsten sicheren Tool-Schritte vor.

Wichtig: Bankkonten müssen vor dem Bankimport angelegt werden. Bankumsätze vor dem Migrationsstichtag sollen normalerweise nicht importiert werden, weil sie bereits im EB-Wert des Bankkontos enthalten sind. Falls sie doch im Export enthalten sind, markiere sie als pre_migration statt sie abzustimmen.

Mit diesem Prompt kann ein MCP-Agent den Wizard über migration(action="start") starten, den Tenant prüfen und die nächsten sicheren Tool-Schritte vorschlagen. Falls dein Agent noch nicht verbunden ist, starte mit dem MCP-Setup.

Prod-Flow

1. Stichtag festlegen — typischerweise der erste Tag eines Monats oder Geschäftsjahres, z. B. 2026-01-01.
2. Altsystem abschließen — bis zum Vortag des Stichtags alle Bankbewegungen, offenen Posten und Abschlussbuchungen im bisherigen System klären.
3. Bankkonten anlegen — jedes reale Bankkonto mit create_bank_account anlegen und einem SKR04-Aktivkonto zuordnen, z. B. 1800 oder einem separaten Bankkonto pro IBAN.
4. EB-Werte buchen — Saldenliste zum Stichtag mit post_opening_balances übernehmen. Der Bank-EB-Wert ist der Startsaldo in LedgerLou.
5. Offene Posten übernehmen — offene Forderungen und Verbindlichkeiten zusätzlich einzeln als offene Posten übernehmen, wenn spätere Zahlungen abgeglichen werden sollen.
6. Bank ab Stichtag importieren — Bankumsätze bevorzugt erst ab dem Migrationsdatum importieren und anschließend normal abstimmen.

Eröffnungsbilanzwerte

Eröffnungsbilanzwerte übertragen die Schlussbilanz des Altsystems als Startbilanz in LedgerLou. Jeder Saldenvortrag wird gegen Konto 9000 (Saldenvorträge Sachkonten) gebucht. Konto 9000 muss sich insgesamt auf Null ausgleichen.

Nur Bilanzkonten werden übernommen:

• Aktiva, z. B. Bank, Kasse, Forderungen, Anlagevermögen
• Passiva, z. B. Verbindlichkeiten, Darlehen, Rückstellungen
• Eigenkapital, z. B. gezeichnetes Kapital, Gewinnvortrag

GuV-Konten starten im neuen Geschäftsjahr bei Null. Das Vorjahresergebnis wird über Gewinnvortrag in der Eröffnungsbilanz abgebildet.

{
  "booking_date": "2026-01-01",
  "balances": [
    { "account_number": "1200", "account_name": "Forderungen aus LuL", "debit": 10000, "credit": 0 },
    { "account_number": "1800", "account_name": "Bank", "debit": 25000, "credit": 0 },
    { "account_number": "2000", "account_name": "Gezeichnetes Kapital", "debit": 0, "credit": 25000 },
    { "account_number": "3300", "account_name": "Verbindlichkeiten aus LuL", "debit": 0, "credit": 10000 }
  ]
}

Offene Posten

Ein aggregierter EB-Saldo auf 1200 oder 3300 reicht für die Bilanz, aber nicht immer für den späteren Bankabgleich. Wenn nach dem Stichtag eine alte Rechnung bezahlt wird, braucht LedgerLou einen einzelnen offenen Posten mit intent_id.

Empfohlene Praxis:

• offene Kreditorenrechnungen einzeln als Verbindlichkeitsbuchung übernehmen und mit create_invoice verknüpfen
• offene Debitorenforderungen einzeln als Forderungsbuchung übernehmen
• nur vollständig historische, nicht mehr zahlungsrelevante Details im Sammel-EB-Saldo belassen

So kann get_reconciliation_suggestions spätere Zahlungen gegen open_receivable oder open_liability vorschlagen.

MCP-Sequenz

{ "action": "start", "migration_date": "2026-01-01", "source_system": "DATEV" }

Danach führt der Agent typischerweise diese Tools aus:

1. migration(action="analyze") — prüfen, was fehlt
2. create_bank_account — Bankkonten anlegen
3. search_accounts / list_accounts — Konten validieren
4. post_opening_balances — EB-Werte buchen
5. post_booking und create_invoice — offene Posten übernehmen
6. import_bank_transactions — Bankumsätze ab Stichtag importieren
7. migration(action="flag_pre_migration_bank_transactions") — nur falls historische Bankumsätze versehentlich mitimportiert wurden
8. get_reconciliation_suggestions und reconcile_bank_transaction — operative Bankabstimmung
9. migration(action="complete") — Migrationsstatus abschließen

Prüfung

Nach der Migration sollten diese Checks grün sein:

• get_bilanz zum Stichtag stimmt mit der Schlussbilanz des Altsystems überein
• get_susa zeigt die erwarteten Anfangssalden
• jedes reale Bankkonto existiert in list_bank_accounts
• es gibt keine offenen Bankumsätze vor dem Migrationsstichtag, außer sie sind als pre_migration markiert
• Bankumsätze ab dem Migrationsstichtag sind importiert und abstimmbar
• offene Forderungen und Verbindlichkeiten, die nach dem Stichtag bezahlt werden, sind einzeln matchbar

Korrektur

Falsche EB-Werte werden nicht geändert, sondern über reverse_booking storniert und anschließend neu gebucht. Falls ein Bank-EB-Wert nicht zum Altsystem-Endsaldo passt, muss der Altabschluss oder der EB-Wert korrigiert werden; historische Bankumsätze werden nicht nachträglich als operative LedgerLou-Abstimmung behandelt.