fix(ausgangsrechnung): Rechnungsnummern pro Jahr zählen — keine Doppelnummer bei Jahres-Rücksprung

H2 (high, §14 Abs.4 Nr.4 UStG / GoBD): Der Nummernkreis hielt EINEN globalen
Zähler {schema, naechste, jahr} und setzte ihn bei jedem Jahreswechsel auf 1
zurück. Rückdatierung ins Vorjahr + Rücksprung ins schon-begonnene Jahr →
Reset → bereits vergebene Nummer erneut. Reproduziert:
[2026-01,2026-02,2025-12,2026-03,2026-04] → RE-2026-0001/0002 DOPPELT.

Datenmodell auf Pro-Jahr-Zähler {zaehler:{<jahr>:<naechste>}} umgestellt:
- vergebeNummer/naechsteNummer zählen je Kalenderjahr unabhängig; Schemata ohne
  {JAHR} teilen einen durchlaufenden Kreis (Schlüssel '*').
- migriereNummern: self-migrating + idempotent; rettet auch manuell gesetzte
  Startwerte ohne `jahr` aufs laufende Jahr (Altzustand des UI-Zweitbefunds),
  statt sie zu verwerfen.
- UI „Nächste Nummer" bezieht sich eindeutig aufs laufende Jahr; persistiert in
  zaehler[key] statt blankem naechste (behebt den latenten Zweitbefund, dass das
  UI nie `jahr` setzte). Schema ohne {NR}-Platzhalter wird abgelehnt.

Verifiziert: Repro-Sequenz jetzt duplikatfrei (5 paarweise verschiedene Nummern);
Migration {jahr:2026,naechste:5}→RE-2026-0005; 307 Tests grün (UTC/Berlin/LA).
Adversarisch refute-reviewt (general-purpose) — Befund „Datenverlust bei
naechste-ohne-jahr" gefunden + 1:1 behoben. Design: .planning/H2-...-DESIGN.md.
Finaler Diff wird beim gated Release-Vet erneut gegengeprüft.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HmxogiBV6uLrvjcui4cC2D

Author: chloepriceless

.planning/H2-RECHNUNGSNUMMER-PRO-JAHR-DESIGN.md

@@ -0,0 +1,97 @@
+# H2 — Doppelte Rechnungsnummern bei Jahres-Rücksprung: Datenmodell-Redesign
+
+_Pfenni, 2026-06-21. R22-kritisch (Datenmodell). Design-vor-Build (Deliberate Mode)._
+
+## Problem (reproduziert)
+`public/shared/ausgangsrechnung.js` hält EINEN globalen Zähler:
+`rechnungsnummern = { schema, naechste, jahr }`. `vergebeNummer` setzt bei
+Jahreswechsel (`rn.jahr !== j`) `naechste = 1` zurück. Bei Rückdatierung ins
+Vorjahr + Rücksprung ins schon-begonnene Jahr → Reset → DOPPELNUMMER.
+
+Repro (`node`): Daten `[2026-01,2026-02,2025-12,2026-03,2026-04]` →
+`RE-2026-0001, RE-2026-0002, RE-2025-0001, RE-2026-0001(!), RE-2026-0002(!)`.
+Verletzt **§ 14 Abs. 4 Nr. 4 UStG** (Einmaligkeit) + **GoBD**. Realistischer
+Pfad: Jahreswechsel-Nacherfassung (Dezember-Rechnung im Januar nachtragen).
+
+Latenter Zweitbefund: UI (`app.js:4188-4198` „Nächste Nummer") setzt nur
+`naechste`, NICHT `jahr` → manuell gesetzter Startwert wird beim nächsten
+Jahreswechsel-Reset verschluckt (wirkungslos, sobald `rn.jahr !== aktuellesJahr`).
+
+## Architektur-Constraints (recherchiert)
+- Rechnungen liegen am **Abschluss** (`a.ausgangsrechnungen`), über Jahre/
+  Abschlüsse verteilt. Der Zähler liegt am **Unternehmen** (`un.rechnungsnummern`).
+  `vergebeNummer(u, datum)` bekommt NUR das Unternehmen, kennt die Rechnungsliste
+  nicht. → „Nummer aus existierenden Rechnungen ableiten" ist architektonisch
+  nicht verfügbar UND GoBD-widrig (gelöschte/stornierte Nummer würde wiederverwendet).
+  Der **persistente Zähler IST die autoritative Quelle** — korrekt, nur global statt
+  pro Jahr. Fix = Zähler pro Jahr, nichts an der Architektur drehen.
+- Dual-Mode: Daten leben im Browser (IndexedDB). Migration muss **self-migrating
+  beim Lesen** sein (kein Migrations-Script), idempotent, rückwärtskompatibel.
+- Konsumenten: `app.js:4133/4193` (UI-Feld), `4590` (`naechsteNummer` Vorschau),
+  `4668` (`vergebeNummer` Vergabe). Tests `tests/run.js:1648-1680`.
+
+## Entscheidung: Zähler pro Jahr als Map
+```js
+rechnungsnummern = {
+  schema: 'RE-{JAHR}-{NR:04}',
+  zaehler: { "2025": 6, "2026": 3 }   // jahr(String) -> NÄCHSTE freie Nr für dieses Jahr
+}
+```
+- `naechsteNummer(u, datum)`: `j = jahrAus(datum); nr = zaehler[j] || 1;` (keine Mutation).
+- `vergebeNummer(u, datum)`: `j; nr = zaehler[j] || 1; zaehler[j] = nr + 1;` → nie Reset
+  eines bereits begonnenen Jahres. Rücksprung ins Vorjahr stellt NUR `zaehler[vorjahr]`
+  weiter, lässt `zaehler[aktuellesJahr]` unberührt → keine Doppelnummer.
+
+### Migration (self-migrating, idempotent) — in `defaults()` zentralisiert
+```js
+function migriereNummern(rn) {
+  if (rn && (!rn.zaehler || typeof rn.zaehler !== 'object')) {
+    rn.zaehler = {};
+    // alten globalen Single-Zähler in das richtige Jahr übernehmen
+    if (rn.jahr > 0 && rn.naechste > 0) rn.zaehler[String(rn.jahr)] = rn.naechste;
+  }
+  return rn;
+}
+```
+Greift genau einmal (sobald `zaehler` existiert, no-op). Verlässt sich nur auf
+`rn`, kein Listen-Zugriff. Alte Felder `jahr`/`naechste` bleiben als toter
+Ballast stehen (NICHT gelöscht — siehe Tradeoff Rückwärtskompat unten).
+
+### UI-Anpassung (app.js Nummernkreis)
+„Nächste Nummer" bezieht sich auf das **laufende Kalenderjahr** (`jahrAus(heute)`):
+- Vorbelegung lesen: `zaehler[lj] || 1`.
+- Speichern: `zaehler[lj] = n` (statt blankes `naechste`). Label präzisieren:
+  „Nächste Nummer (laufendes Jahr <LJ>)". Behebt den latenten Zweitbefund.
+
+## Verworfene Alternativen
+1. **Nummer aus `a.ausgangsrechnungen` max+1 ableiten.** Verworfen: Architektur
+   (Liste nicht in `vergebeNummer` verfügbar, über Abschlüsse verteilt) + GoBD
+   (Wiederverwendung gelöschter Nummern). Der persistente Zähler existiert genau
+   deshalb.
+2. **Single-Zähler behalten, Reset nur bei `j > rn.jahr` (monoton vorwärts).**
+   Verworfen: bei Rückdatierung ins Vorjahr würde der Vorjahres-Zähler vom
+   aktuellen Jahr „mitgezählt" → falsche/springende Vorjahresnummern; und ein
+   zweites Vorjahr (2024 nach 2026) bekäme keinen sauberen eigenen Kreis. Pro-Jahr
+   ist das einzig saubere Modell für jahresbasierte Schemata.
+3. **Legacy-Felder bei Migration löschen.** Verworfen (vorerst): eine alte App-
+   Version aus dem SW-Cache, die dieselben IDB-Daten lädt, würde ohne `zaehler`
+   wieder auf `jahr`/`naechste` zurückfallen. Sie stehenzulassen schadet nicht;
+   `zaehler` ist eindeutig die neue autoritative Quelle. (Defensive Spiegelung der
+   Legacy-Felder beim Vergeben erwogen, aber als Überkomplexität verworfen — nach
+   einem Reload ist die alte App ohnehin weg.)
+
+## Risiken / Kanten (zu prüfen)
+- Schemata OHNE `{JAHR}` (z. B. fortlaufend über Jahre, `RE-{NR:05}`). Dann ist
+  „pro Jahr" semantisch falsch — der User WILL einen durchlaufenden Kreis. → Muss
+  behandelt werden: wenn das Schema kein `{JAHR}` enthält, EINEN gemeinsamen Kreis
+  führen (z. B. `zaehler['*']`), nicht pro Kalenderjahr. **Kernfrage für Codex.**
+- `jahrAus` Default = aktuelles Jahr bei leerem/ungültigem Datum — unverändert ok.
+- Idempotenz der Migration bei wiederholtem `defaults()`-Aufruf — durch `zaehler`-
+  Existenzprüfung gegeben.
+
+## Verifikation (Oracle)
+- Repro-Sequenz `[2026-01,2026-02,2025-12,2026-03,2026-04]` → 5 PAARWEISE
+  VERSCHIEDENE Nummern (`RE-2026-0001/0002, RE-2025-0001, RE-2026-0003, RE-2026-0004`).
+- Migration: altes `{jahr:2026,naechste:5}` → erste Vergabe 2026 = `RE-2026-0005`.
+- Bestehende Tests (`run.js:1648ff`) angepasst + neue Regressionstests für
+  Rücksprung + Migration + schema-ohne-JAHR. `node tests/run.js` grün.

CHANGELOG.md

@@ -45,6 +45,16 @@ nachvollziehbar, welcher Programmstand einen Abschluss erzeugt hat.
   4180 (Durchschnittssätze § 24 UStG, Land-/Forstwirtschaft). Jetzt korrekt
   getrennt: innergem. Lieferung → 4125 (§ 4 Nr. 1b UStG), sonstige steuerfreie
   Umsätze → 4150 (§ 4 Nr. 2-7 UStG).
+- **Doppelte Rechnungsnummern bei Jahres-Rücksprung:** Der Rechnungsnummernkreis
+  führte nur einen globalen Zähler und setzte ihn bei jedem Jahreswechsel auf 1
+  zurück. Wurde nach Rechnungen des laufenden Jahres eine Rechnung ins Vorjahr
+  rückdatiert und danach wieder im laufenden Jahr fortgefahren, vergab der Zähler
+  bereits benutzte Nummern erneut (Verstoß gegen § 14 Abs. 4 Nr. 4 UStG /
+  GoBD). Jetzt führt jedes Kalenderjahr einen eigenen, lückenlosen Kreis
+  (Schemata ohne `{JAHR}` einen durchlaufenden) — das Datenmodell migriert
+  bestehende Zählerstände self-migrating. Das Stammdaten-Feld „Nächste Nummer"
+  bezieht sich nun eindeutig auf das laufende Jahr; ein Nummernschema ohne
+  `{NR}`-Platzhalter wird beim Speichern abgelehnt.
 
 ### Sicherheit / Robustheit
 - **E-Bilanz-Validierung gehärtet** (`lib/validate.js`): doppelter Callback im

public/app.js

@@ -4122,15 +4122,29 @@ function renderKunden(m) {
   html += '</div>';
 
   /* --- Rechnungsnummernkreis -------------------------------------------- */
+  /* Pro-Jahr-Zähler: das Feld „Nächste Nummer" bezieht sich auf das laufende
+   * Kalenderjahr (bzw. den durchlaufenden Kreis bei Schemata ohne {JAHR}). */
+  var nrLj      = new Date().getFullYear();
+  var nrObj     = (u && u.rechnungsnummern) || {};
+  var nrSchema  = nrObj.schema || 'RE-{JAHR}-{NR:04}';
+  var nrProJahr = /\{JAHR\}/.test(nrSchema);
+  var nrKey     = nrProJahr ? String(nrLj) : '*';
+  var nrNaechste = (nrObj.zaehler && nrObj.zaehler[nrKey] > 0) ? nrObj.zaehler[nrKey]
+                 : ((nrObj.jahr === nrLj && nrObj.naechste > 0) ? nrObj.naechste : 1);
+  var nrLabel   = nrProJahr ? ('Nächste Nummer (Jahr ' + nrLj + ')')
+                            : 'Nächste Nummer (durchlaufend)';
   html += '<div class="karte"><h2>Rechnungsnummernkreis</h2>' +
           '<div class="karte-hint">§ 14 Abs. 4 Nr. 4 UStG verlangt eine ' +
           'einmalig vergebene Rechnungsnummer. Platzhalter: ' +
           '<code>{JAHR}</code> für das Rechnungsjahr, <code>{NR:04}</code> für ' +
-          'die nächste Nummer mit vier Stellen führender Null. Beim Jahreswechsel ' +
-          'wird der Zähler automatisch zurückgesetzt.</div>' +
+          'die nächste Nummer mit vier Stellen führender Null. Mit <code>{JAHR}</code> ' +
+          'führt jedes Kalenderjahr einen eigenen, lückenlosen Kreis — auch bei ' +
+          'nachträglich rückdatierten Rechnungen entsteht keine Doppelnummer.</div>' +
           '<div class="gitter g2">' +
           fv('rechnungsnummern.schema',    'Nummernschema', 'z. B. RE-{JAHR}-{NR:04}') +
-          fv('rechnungsnummern.naechste',  'Nächste Nummer', 'einmalig manuell anpassbar, z. B. nach Migration', 'number') +
+          feldWrap(nrLabel, 'einmalig manuell anpassbar, z. B. nach Migration',
+            '<input data-u="rechnungsnummern.naechste" type="number" min="1" value="' +
+            esc(nrNaechste) + '">') +
           '</div>' +
           '<div class="btn-reihe"><button class="btn" id="nrSpeichern">' +
           'Nummernkreis speichern</button></div>' +
@@ -4187,12 +4201,25 @@ function renderKunden(m) {
   /* Nummernkreis speichern */
   m.querySelector('#nrSpeichern').onclick = function () {
     var un = JSON.parse(JSON.stringify(u));
-    un.rechnungsnummern = un.rechnungsnummern || {};
-    un.rechnungsnummern.schema = m.querySelector('[data-u="rechnungsnummern.schema"]').value.trim()
+    /* Altdaten erst self-migrating auf den Pro-Jahr-Zähler heben, damit
+     * historische Jahres-Zählerstände nicht durch das Speichern verloren gehen. */
+    Ausgangsrechnung.defaults(un);
+    var schema = m.querySelector('[data-u="rechnungsnummern.schema"]').value.trim()
       || 'RE-{JAHR}-{NR:04}';
+    /* Ohne {NR}-Platzhalter wäre jede Rechnungsnummer identisch — § 14 Abs. 4
+     * Nr. 4 UStG verlangt eine einmalig vergebene Nummer. Schema ablehnen. */
+    if (!/\{NR(?::\d+)?\}/.test(schema)) {
+      alert('Das Nummernschema muss den Platzhalter {NR} (z. B. {NR:04}) für die '
+        + 'fortlaufende Nummer enthalten — sonst wäre keine Rechnungsnummer eindeutig.');
+      return;
+    }
+    un.rechnungsnummern.schema = schema;
     var n = parseInt(m.querySelector('[data-u="rechnungsnummern.naechste"]').value, 10);
     if (!(n > 0)) n = 1;
-    un.rechnungsnummern.naechste = n;
+    /* „Nächste Nummer" bezieht sich auf das laufende Jahr (bzw. den
+     * durchlaufenden Kreis bei Schemata ohne {JAHR}). */
+    var key = /\{JAHR\}/.test(schema) ? String(new Date().getFullYear()) : '*';
+    un.rechnungsnummern.zaehler[key] = n;
     Store.speichereUnternehmen(un).then(function (g) {
       if (g && !g.fehler) { S.unternehmen = g; hinweisToast('Nummernkreis gespeichert.'); }
     });

public/shared/ausgangsrechnung.js

@@ -56,11 +56,41 @@
   }
   function cent(n) { return Math.round((num(n) + Number.EPSILON) * 100) / 100; }
 
+  /* Schlüssel im Pro-Jahr-Zähler. Schemata MIT {JAHR} bekommen je Kalenderjahr
+   * einen eigenen, lückenlosen Kreis; Schemata OHNE {JAHR} (durchlaufende
+   * Nummerierung) teilen sich den gemeinsamen Schlüssel '*'. */
+  function zaehlerKey(schema, datum) {
+    return /\{JAHR\}/.test(String(schema || 'RE-{JAHR}-{NR:04}'))
+      ? String(jahrAus(datum)) : '*';
+  }
+  /* Migriert das alte Single-Zähler-Modell { jahr, naechste } self-migrating
+   * (idempotent) auf den Pro-Jahr-Zähler { zaehler: { <jahr>: <naechste> } }.
+   * Behebt H2: ein globaler Zähler wurde bei Rücksprung ins schon-begonnene
+   * Jahr fälschlich auf 1 zurückgesetzt → Doppelnummer (§ 14 Abs. 4 Nr. 4 UStG).
+   * Greift genau einmal — sobald `zaehler` existiert, ist es ein No-Op. */
+  function migriereNummern(rn) {
+    if (rn && (!rn.zaehler || typeof rn.zaehler !== 'object')) {
+      rn.zaehler = {};
+      /* Alten Single-Zähler übernehmen. Bei {JAHR}-Schema ohne gültiges `jahr`
+       * (Altzustand des UI-Zweitbefunds: `naechste` wurde ohne `jahr` gesetzt)
+       * den manuell gesetzten Startwert auf das laufende Kalenderjahr RETTEN,
+       * statt ihn zu verwerfen — sonst lautloser Verlust + Reset-auf-1 mit
+       * Doppelnummern-Potenzial (§ 14 Abs. 4 Nr. 4 UStG / GoBD). */
+      if (rn.naechste > 0) {
+        var key = /\{JAHR\}/.test(String(rn.schema || 'RE-{JAHR}-{NR:04}'))
+          ? String(rn.jahr > 0 ? rn.jahr : new Date().getFullYear()) : '*';
+        rn.zaehler[key] = rn.naechste;
+      }
+    }
+    return rn;
+  }
+
   function defaults(u) {
     var d = u || {};
     if (!d.kunden)         d.kunden = [];
     if (!d.rechnungsnummern) d.rechnungsnummern = { schema: 'RE-{JAHR}-{NR:04}',
-                                                     naechste: 1, jahr: 0 };
+                                                     zaehler: {} };
+    migriereNummern(d.rechnungsnummern);
     if (!d.rechnungsAngaben) d.rechnungsAngaben = {};
     return d;
   }
@@ -105,19 +135,22 @@
     var d = defaults(u);
     var rn = d.rechnungsnummern;
     var j = jahrAus(datum);
-    var nr = (rn.jahr === j) ? rn.naechste : 1;
+    var nr = rn.zaehler[zaehlerKey(rn.schema, datum)] || 1;
     return formatNummer(rn.schema, j, nr);
   }
-  /* Tatsächlicher Vergabevorgang: Zähler weiterstellen, neue Nummer
-   * zurückgeben. Stellt Jahreswechsel um. */
+  /* Tatsächlicher Vergabevorgang: Zähler des betroffenen Jahres weiterstellen,
+   * neue Nummer zurückgeben. Jeder Kalenderjahr-Kreis (bzw. der durchlaufende
+   * Kreis bei Schemata ohne {JAHR}) zählt unabhängig — ein Rücksprung ins
+   * Vorjahr stellt NUR dessen Zähler weiter und lässt das laufende Jahr
+   * unberührt (kein fälschlicher Reset → keine Doppelnummer). */
   function vergebeNummer(u, datum) {
     var d = defaults(u);
     var rn = d.rechnungsnummern;
     var j = jahrAus(datum);
-    if (rn.jahr !== j) { rn.jahr = j; rn.naechste = 1; }
-    var nummer = formatNummer(rn.schema, j, rn.naechste);
-    rn.naechste = (rn.naechste || 1) + 1;
-    return nummer;
+    var key = zaehlerKey(rn.schema, datum);
+    var nr = rn.zaehler[key] || 1;
+    rn.zaehler[key] = nr + 1;
+    return formatNummer(rn.schema, j, nr);
   }
   /* Wählt das passende Erlös-/USt-Konto für eine Position abhängig von der
    * Steuerlogik der Rechnung und vom Steuersatz der Position. */

tests/run.js

@@ -1650,16 +1650,68 @@ test('Ausgangsrechnung: vergebeNummer ist lückenlos und springt am Jahreswechse
   eq(Ausgangsrechnung.vergebeNummer(u, '2026-05-20'), 'RE-2026-0001', 'erste 2026');
   eq(Ausgangsrechnung.vergebeNummer(u, '2026-06-01'), 'RE-2026-0002', 'zweite 2026');
   eq(Ausgangsrechnung.vergebeNummer(u, '2026-12-31'), 'RE-2026-0003', 'dritte 2026');
-  eq(Ausgangsrechnung.vergebeNummer(u, '2027-01-02'), 'RE-2027-0001', 'reset bei Jahreswechsel');
-  eq(u.rechnungsnummern.naechste, 2, 'Zähler steht auf 2');
-  eq(u.rechnungsnummern.jahr, 2027, 'Jahr aktualisiert');
+  eq(Ausgangsrechnung.vergebeNummer(u, '2027-01-02'), 'RE-2027-0001', 'eigener Kreis je Jahr');
+  eq(u.rechnungsnummern.zaehler['2026'], 4, 'Zähler 2026 steht auf 4');
+  eq(u.rechnungsnummern.zaehler['2027'], 2, 'Zähler 2027 steht auf 2');
+});
+
+/* H2-Regression (§ 14 Abs. 4 Nr. 4 UStG): Rückdatierung ins Vorjahr + Rücksprung
+ * ins schon-begonnene Jahr darf KEINE Doppelnummer erzeugen. */
+test('Ausgangsrechnung: H2 — Jahres-Rücksprung erzeugt keine Doppelnummer', function () {
+  var u = {};
+  var seq = ['2026-01-15', '2026-02-15', '2025-12-20', '2026-03-10', '2026-04-05'];
+  var nums = seq.map(function (d) { return Ausgangsrechnung.vergebeNummer(u, d); });
+  eq(nums.join(','),
+     'RE-2026-0001,RE-2026-0002,RE-2025-0001,RE-2026-0003,RE-2026-0004',
+     'Vorjahr-Einschub stellt nur den 2025er-Kreis weiter, 2026 läuft lückenlos fort');
+  var uniq = nums.filter(function (n, i) { return nums.indexOf(n) === i; });
+  eq(uniq.length, nums.length, 'alle vergebenen Nummern sind paarweise verschieden');
+});
+
+/* Self-migrating: altes Single-Zähler-Modell { jahr, naechste } übernimmt den
+ * Stand in den richtigen Jahres-Kreis. */
+test('Ausgangsrechnung: Migration Single-Zähler -> Pro-Jahr', function () {
+  var u = { rechnungsnummern: { schema: 'RE-{JAHR}-{NR:04}', naechste: 5, jahr: 2026 } };
+  eq(Ausgangsrechnung.vergebeNummer(u, '2026-05-20'), 'RE-2026-0005', 'setzt bei 5 fort (kein Reset auf 1)');
+  eq(Ausgangsrechnung.vergebeNummer(u, '2025-11-01'), 'RE-2025-0001', 'Vorjahr startet eigenen Kreis');
+  eq(u.rechnungsnummern.zaehler['2026'], 6, '2026-Kreis fortgeschrieben');
 });
 
 test('Ausgangsrechnung: naechsteNummer mutiert nicht (Vorschau)', function () {
   var u = { rechnungsnummern: { schema: 'RE-{JAHR}-{NR:04}', naechste: 5, jahr: 2026 } };
   eq(Ausgangsrechnung.naechsteNummer(u, '2026-05-20'), 'RE-2026-0005', 'Vorschau 5');
   eq(Ausgangsrechnung.naechsteNummer(u, '2026-05-20'), 'RE-2026-0005', 'noch immer 5 (keine Mutation)');
-  eq(u.rechnungsnummern.naechste, 5, 'Zähler unverändert');
+  eq(u.rechnungsnummern.zaehler['2026'], 5, 'Zähler unverändert');
+});
+
+/* Schema ohne {JAHR}: durchlaufende Nummerierung, kein Jahres-Reset. */
+test('Ausgangsrechnung: Schema ohne {JAHR} zählt durchlaufend über Jahresgrenzen', function () {
+  var u = { rechnungsnummern: { schema: 'R{NR:05}', zaehler: {} } };
+  eq(Ausgangsrechnung.vergebeNummer(u, '2026-12-30'), 'R00001', 'erste');
+  eq(Ausgangsrechnung.vergebeNummer(u, '2027-01-02'), 'R00002', 'kein Reset im neuen Jahr');
+  eq(Ausgangsrechnung.vergebeNummer(u, '2026-06-01'), 'R00003', 'Rücksprung zählt im selben Kreis weiter');
+  eq(u.rechnungsnummern.zaehler['*'], 4, 'gemeinsamer Zähler steht auf 4');
+});
+
+/* Migration rettet einen manuell gesetzten Startwert OHNE `jahr` (Altzustand des
+ * UI-Zweitbefunds) auf das laufende Jahr, statt ihn zu verwerfen → kein Reset
+ * auf 1, keine Doppelnummer (§ 14 Abs. 4 Nr. 4 UStG). */
+test('Ausgangsrechnung: Migration rettet naechste ohne jahr aufs laufende Jahr', function () {
+  var lj = String(new Date().getFullYear());
+  var u = { rechnungsnummern: { schema: 'RE-{JAHR}-{NR:04}', naechste: 48 } };
+  Ausgangsrechnung.defaults(u);
+  eq(u.rechnungsnummern.zaehler[lj], 48, 'Startwert 48 ins laufende Jahr gerettet');
+  eq(Ausgangsrechnung.vergebeNummer(u, lj + '-03-01'), 'RE-' + lj + '-0048',
+     'erste Vergabe setzt bei 48 fort, kein Reset auf 1');
+});
+
+/* Migration ist idempotent: wiederholtes defaults() verändert den Zähler nicht. */
+test('Ausgangsrechnung: Migration ist idempotent', function () {
+  var u = { rechnungsnummern: { schema: 'RE-{JAHR}-{NR:04}', naechste: 3, jahr: 2026 } };
+  Ausgangsrechnung.defaults(u);
+  eq(u.rechnungsnummern.zaehler['2026'], 3, 'einmal migriert');
+  Ausgangsrechnung.defaults(u);
+  eq(u.rechnungsnummern.zaehler['2026'], 3, 'zweiter Aufruf ist No-Op');
 });
 
 test('Ausgangsrechnung: eigeneAusUnternehmen — rechnungsAngaben überschreibt Hauptfelder', function () {