diff --git a/README.md b/README.md
index 51b150d..18540aa 100644
--- a/README.md
+++ b/README.md
@@ -15,6 +15,8 @@ Before this package, `taxBreakdown.ts` and `correctionInvoicePdf.tsx` were hand-
One canonical implementation, consumed by both repos, makes this class of drift structurally impossible instead of relying on manual vigilance.
+**2026-07-23, Phase 2:** `InvoiceSeller.bankDetails` (a free-text textarea on `company-settings`) became structured `iban`/`bic` fields — EN16931 e-invoicing wants discrete PaymentMeans data, not a paragraph a human formatted by hand. The footer's bank-details line also changed from "Bankverbindung (für Überweisung): …" to plain "Bankverbindung: IBAN … · BIC …", shown whenever either is set — it was never actually conditional on the order's payment method (that label was misleading), and there's no reason to hide it from a card/PayPal customer who might still want it (e.g. for a refund).
+
## How this is consumed
Not published to npm — installed as a git dependency:
diff --git a/src/correctionInvoicePdf.tsx b/src/correctionInvoicePdf.tsx
index cc70988..8f1397a 100644
--- a/src/correctionInvoicePdf.tsx
+++ b/src/correctionInvoicePdf.tsx
@@ -300,7 +300,13 @@ function CorrectionInvoiceDocument({ kind, order, seller }: { kind: CorrectionIn
{seller.registerCourt && seller.registerNumber ? ` · ${seller.registerCourt} · ${seller.registerNumber}` : ""}
{seller.managingDirector ? ` · Geschäftsführung: ${seller.managingDirector}` : ""}
- {seller.bankDetails ? Bankverbindung (für Überweisung): {seller.bankDetails} : null}
+ {/* Always shown when set, regardless of payment method — see
+ invoicePdf.tsx's own comment on this same line. */}
+ {(seller.iban || seller.bic) && (
+
+ Bankverbindung: {[seller.iban && `IBAN ${seller.iban}`, seller.bic && `BIC ${seller.bic}`].filter(Boolean).join(" · ")}
+
+ )}
diff --git a/src/invoicePdf.tsx b/src/invoicePdf.tsx
index 78fe802..f72c2a4 100644
--- a/src/invoicePdf.tsx
+++ b/src/invoicePdf.tsx
@@ -334,7 +334,15 @@ export function InvoiceDocument({ order, seller }: { order: InvoiceOrder; seller
{seller.registerCourt && seller.registerNumber ? ` · ${seller.registerCourt} · ${seller.registerNumber}` : ""}
{seller.managingDirector ? ` · Geschäftsführung: ${seller.managingDirector}` : ""}
- {seller.bankDetails ? Bankverbindung (für Überweisung): {seller.bankDetails} : null}
+ {/* Always shown when set, regardless of payment method — not
+ gated on "Überweisung" specifically (a customer who paid by
+ card can still want the seller's bank details for other
+ reasons, e.g. a refund) — see this package's README. */}
+ {(seller.iban || seller.bic) && (
+
+ Bankverbindung: {[seller.iban && `IBAN ${seller.iban}`, seller.bic && `BIC ${seller.bic}`].filter(Boolean).join(" · ")}
+
+ )}
diff --git a/src/seller.ts b/src/seller.ts
index 799a5e0..9e4fe01 100644
--- a/src/seller.ts
+++ b/src/seller.ts
@@ -11,7 +11,12 @@ export type InvoiceSeller = {
sellerEmail: string;
vatId: string;
taxRatePercent: number;
- bankDetails?: string | null;
+ // Structured (Phase 2 of the e-invoicing migration — EN16931 wants
+ // discrete PaymentMeans data, not a free-text paragraph a human
+ // formatted by hand) — replaces what used to be a single `bankDetails`
+ // textarea field.
+ iban?: string | null;
+ bic?: string | null;
// Pflichtangaben in Geschäftsbriefen for registered legal forms (§37a
// HGB / §35a GmbHG) — optional because a sole proprietorship (the
// default legalForm in company-settings) has neither.