SaaS UX for the German market: Impressum, cookie consent and du or Sie

German has two ways to say "you": informal du and formal Sie. English copy hides the choice, so teams often meet it when the translation lands and end up with both: du on the website, Sie in the app.

A useful reference is Microsoft's German localisation style guide (April 2026 edition). It writes product examples with Sie and tells translators to use du for children and teens under 18. That's one company's choice, not a rule, but it shows where formal software German sits.

My view: for B2B SaaS sold to owner-managed companies, finance or HR teams, I start from Sie. For a consumer app or developer tool with a younger audience, du can fit, if the brand can carry it in a failed payment message too. The worst result is a mix.

What the choice changes:

• Sie and its forms (Ihr, Ihnen) are capitalised and the verbs change, so every helper text and error has to be written in the chosen form.
• I keep buttons in the infinitive ("Speichern", "Kündigen"), which reads the same either way.
• Every third-party surface needs the same setting: payment page, cookie tool, emails, help centre, app store listing.

I'm not a German copywriter. The words come from your team or translator; my job is making the system hold them.

The W3C article on text size in translation quotes IBM's figures: the average expansion for English strings of up to 10 characters is 200 to 300%, falling to 130% over 70 characters. So buttons, tabs and table headers break first. Its example: "Input processing features" becomes "Eingabeverarbeitungsfunktionen", one word that cannot wrap. On a signup form, "Work email" is 10 characters; "Geschäftliche E-Mail-Adresse" is 28.

How I design for it:

• Labels sit above fields, buttons grow with their text, and tabs have no fixed width.
• Narrow headers wrap with hyphens: auto on a page marked lang="de". The MDN reference for hyphens notes browsers only hyphenate when the language is set and a dictionary is available, so I add soft hyphens (­) to known long words in navigation.
• Truncation is for user data such as long company names, with the full value on hover and focus. Never for labels.

Formats change too. In my Node.js test (CLDR 48), German gives 1.234,50 €, 10.10.2026, 14:30 and 12,5 %. Format from the locale in code, never by hand.

Since 14 May 2024 the Impressum duty has lived in the Digitale-Dienste-Gesetz, which replaced the Telemediengesetz. The IHK Nordschwarzwald's note on the change says pages still citing § 5 TMG should be updated, and that the TTDSG is now the TDDDG.

§ 5 DDG covers commercial digital services usually offered for payment, which describes almost every SaaS product. The information must be easy to recognise, directly reachable and permanently available. It includes name and address (for companies, legal form and representatives), fast electronic contact including email, the register number, the VAT ID where there is one, and the supervisory authority if the activity needs approval.

How I design it in:

• The link says "Impressum", the word German users look for, not just "Legal".
• It sits in the website footer, on signup and checkout, in the logged-in app's help menu and in the mobile app's settings: one click or tap from any screen.
• It's real text, not an image. Your lawyer writes it; I make it easy to find.

§ 25 TDDDG allows storing or reading information on a device only with consent based on clear information, judged by the GDPR. The exception is storage strictly necessary for a service the user explicitly asked for, such as staying logged in.

The GDPR's Articles 4(11) and 7 define consent as freely given, specific, informed and unambiguous. You must be able to show it, and withdrawing must be as easy as giving it. The CJEU's Planet49 judgment (C-673/17) of 1 October 2019 added that a pre-ticked checkbox is not consent, whether or not the data is personal, and that users must be told how long cookies last and whether third parties can access them.

The DSK's guidance for digital service providers (version 1.2, November 2024), from Germany's data protection authorities, spells out the design:

• no cookies needing consent on the first page load, before anyone is asked (para. 36);
• "Alles akzeptieren" beside only "Einstellungen" or "Details" is not valid consent (para. 49);
• reject must be an equal alternative, for example a button comparable in size, colour, contrast and typeface (para. 135), and "Einstellungen oder Ablehnen" opening a second layer is not enough (para. 137);
• withdrawal must work the way consent did, through a link or icon that stays visible, not only by email and not through a contact form (para. 62).

In SaaS this reaches into the logged-in app. Product analytics, session replay and chat widgets usually store or read something on the device; whether that's strictly necessary is for your data protection officer to judge. I design for the answer being consent: off by default, a privacy page in the account, and a record of which banner version someone saw.

If any customers are consumers, German civil law names two buttons. § 312j BGB says the button placing a paid order must say nothing but "zahlungspflichtig bestellen" or an equally clear wording; otherwise no contract is formed. A paid plan that starts on "Jetzt starten" is a risk, and trials that convert need your lawyer to say which step is the paid order.

§ 312k BGB covers subscriptions concluded online: a "Verträge hier kündigen" button leading to a confirmation page with "jetzt kündigen", both permanently available and easy to reach, then a confirmation in text form. Without it, consumers can cancel at any time without notice.

I put the cancel button in the website footer and on the billing page, and keep the confirmation page to one short form. B2B-only products aren't bound by these consumer rules, but an honest cancel flow still reads well to a careful buyer.

B2B buyers in Germany ask the same questions before they sign, often with a data protection officer in the room. I'd rather the product answered them. It's the part of the trust screens I design for Berlin SaaS teams that procurement reads most closely.

For US providers, the European Commission adopted an adequacy decision for the EU-US Data Privacy Framework on 10 July 2023, covering US companies that take part. List which providers rely on it. Adding AI? My notes on explaining AI features people trust cover the data screens. Selling into the Baltics too? See Smart-ID and Mobile-ID sign-in.

§ 1 BFSG covers services provided to consumers after 28 June 2025, including consumer banking, e-books and e-commerce services. § 2 BFSG defines e-commerce services as digital services through websites and mobile apps, provided at a consumer's request with a view to a consumer contract: in practice, any consumer signup or checkout. It also defines micro-enterprises (fewer than 10 employees, at most €2 million turnover or balance sheet total), which the federal government's BFSG questions and answers confirm are exempt for services. § 37 BFSG sets fines of up to €100,000.

Pure B2B SaaS is probably outside it; your lawyer decides. My standard doesn't change: WCAG 2.1 AA as the floor, 2.2 AA as the target. The consent banner gets the same care: focus moves into it, reading order matches the visual order, both buttons work by keyboard. The BFSG implements the same EU directive as the European Accessibility Act for Dutch teams, so one market's work carries to the other.

The Bundesbank's Zahlungsverhalten in Deutschland 2025, published 17 June 2026, surveyed 6,070 people between 8 September and 2 December 2025. For online purchases, internet payment methods such as PayPal, Klarna and Apple Pay made up 50% of transactions, direct debit and bank transfer 30%, credit cards 15% and debit cards 4%. By value, direct debit and transfer led with 45%.

PayPal had about 86% of internet payment transactions, and of respondents with a bank account who use the internet, 77% had PayPal set up and 48% Klarna. This is consumer shopping, not SaaS subscriptions, but a card-only checkout clearly misses much of how people here pay.

Direct debit needs its own states. Stripe's SEPA Direct Debit documentation says customers give their name and IBAN and accept a mandate, you should wait at least 6 business days before treating a payment as successful, and customers can dispute a debit, no questions asked, for eight weeks. So I design a "Zahlung in Bearbeitung" (payment processing) state that doesn't lock anyone out, plus failed and refunded states.

For B2B, invoices matter too. IHK Köln's guide to e-invoices says German businesses have had to be able to receive e-invoices since 1 January 2025, and a PDF by email no longer counts as one. Issuers may still send paper, or PDFs the recipient agrees to, through 2026, and in 2027 only with prior-year turnover up to €800,000; from 2028, EN 16931 e-invoices are required. Billing settings need the legal company name, address, VAT ID, a purchase order field and an accounts payable email.

1. Intro call. Who the German users are (companies, consumers or both), which plans they buy, and what launches when.
2. Decide the voice. Du or Sie, written into the design system with examples.
3. Get real German strings from your translator, then stress-test every component.
4. List the legal surfaces: Impressum, privacy notice, consent, order and cancel buttons. Your lawyer supplies the text.
5. Design consent, testing the reject path before the accept path.
6. Accessibility pass by keyboard and screen reader on signup, consent and checkout.
7. Payment and invoice states: pending direct debit, failures, refunds, invoice details.
8. Handoff or build: specs for your developers, or my team builds the front end in React and Next.js.

Start with the two decisions that touch every screen: du or Sie, and how components carry German text. Both are cheap in week one and expensive in month six. Then the legal surfaces, which are small to design but painful to retrofit. For the rest of a SaaS product, I use this UX audit checklist.

That's the work behind my product design work for Berlin SaaS teams, part of my wider product design for SaaS teams. You can read how I work and who my team is. A project starts with a free 30 minute intro call, then a written scope and one fixed quote.

Should a German SaaS app use du or Sie?

There's no single rule. Microsoft's German style guide writes product text with Sie and uses du for under-18s. For B2B products I start from Sie; for consumer or developer products with a younger audience, du can fit. What matters most is one form across the app, emails, banner and checkout.

Does a SaaS product need an Impressum in Germany?

Almost certainly, if it's a commercial service usually offered for payment. § 5 DDG requires your name, address, legal form and representatives, electronic contact including email, register number and VAT ID where you have one. It must be easy to recognise, directly reachable and permanently available, so link it from every page and app screen.

Is a cookie banner required in Germany?

Only if you store or read information on devices for purposes that aren't strictly necessary, which covers most analytics, advertising and many chat or replay tools. § 25 TDDDG then requires opt-in consent before anything is set. Ask your data protection officer to classify each tool.

Must the reject button look the same as accept?

Close to it. The German authorities' guidance says refusing must be an equal alternative, for example a button comparable in size, colour, contrast and typeface. "Alles akzeptieren" beside only "Einstellungen" is not valid consent, and neither is an "Einstellungen oder Ablehnen" button that opens a second layer.

Does the BFSG apply to B2B SaaS?

Usually not to pure B2B. The BFSG covers services provided to consumers, including e-commerce through websites and apps with a view to a consumer contract. A consumer signup, checkout or app may be covered. Micro-enterprises under 10 employees and at most €2 million turnover are exempt for services. Your lawyer confirms the scope.

How much longer is German text than English?

It depends on length. IBM figures quoted by the W3C put average expansion at 200 to 300% for English strings of up to 10 characters, falling to 130% over 70 characters. Buttons and tabs suffer most, and long compounds can't wrap. Design components with real German strings from the start.

Which payment methods should a German SaaS checkout offer?

Start from what people use. In the Bundesbank's 2025 study, internet payment methods had 50% of online transactions, PayPal about 86% of those, and direct debit or transfer 30%. For consumers, I'd offer PayPal, SEPA Direct Debit and cards; for B2B, direct debit and invoice payment with proper e-invoices.

What does "zahlungspflichtig bestellen" mean for a SaaS signup?

It's the label § 312j BGB requires on the button that places a paid order with a consumer, or an equally clear wording. Without it, no contract is formed. For a free trial that turns into a paid plan, ask your lawyer which step is the paid order, then label that button.

I read every source on 5 October 2026, unless a date says otherwise. German translations are mine. Formats come from my Node.js 24.14.1 test (ICU 78.2, CLDR 48). Data is thin on how German users pay for SaaS subscriptions: the Bundesbank figures cover all consumer online purchases. Nothing here is legal advice.

• Federal Ministry of Justice, § 5 DDG (Impressum), date read 5 October 2026: gesetze-im-internet.de
• IHK Nordschwarzwald, TMG becomes the DDG (14 May 2024; TTDSG renamed TDDDG), date read 5 October 2026: ihk.de
• Federal Ministry of Justice, § 25 TDDDG, date read 5 October 2026: gesetze-im-internet.de
• EUR-Lex, GDPR, Articles 4(11), 7, 28, 45 and 46, date read 5 October 2026: eur-lex.europa.eu
• EUR-Lex, CJEU judgment in Planet49, C-673/17, 1 October 2019, date read 5 October 2026: eur-lex.europa.eu
• Datenschutzkonferenz, OH Digitale Dienste, version 1.2, November 2024, paras. 36, 49, 53, 62, 135, 137, date read 5 October 2026: datenschutzkonferenz-online.de
• Federal Ministry of Justice, §§ 312j and 312k BGB (order and cancellation buttons), date read 5 October 2026: gesetze-im-internet.de, gesetze-im-internet.de
• European Commission, EU-US data transfers (adequacy decision of 10 July 2023), date read 5 October 2026: commission.europa.eu
• Federal Ministry of Justice, §§ 1, 2 and 37 BFSG, date read 5 October 2026: gesetze-im-internet.de, gesetze-im-internet.de, gesetze-im-internet.de
• Bundesregierung, questions and answers on the BFSG, date read 5 October 2026: bundesregierung.de
• W3C Internationalization, Text size in translation, date read 5 October 2026: w3.org
• MDN Web Docs, hyphens, date read 5 October 2026: developer.mozilla.org
• Microsoft, German Localization Style Guide (April 2026), date read 5 October 2026: download.microsoft.com
• Deutsche Bundesbank, Zahlungsverhalten in Deutschland 2025 (17 June 2026), figures 2.4.1, 4.5.1, 4.5.2, date read 5 October 2026: bundesbank.de
• Stripe, SEPA Direct Debit documentation, date read 5 October 2026: docs.stripe.com
• IHK Köln, E-Rechnungen, date read 5 October 2026: ihk.de