Compliance map · Draft for Steuerberater review

The legal flow of a single order.

Every step we are legally obliged to perform when a customer buys something — from the moment they arrive on the site, through payment and shipping, to the ten-year retention window — mapped to the service that covers each obligation.

Draft for review. This map is a structured starting point for the architecture conversation. It cites German law (BGB, UStG, PAngV, TMG, DSGVO, GoBD, AO, TTDSG) but is not legal advice — the final version must be reviewed and signed off by our Steuerberater and, where relevant, a lawyer (especially the Widerrufsbelehrung, the AGB, and the Verfahrensdokumentation for GoBD).
Scope · EU-only sales. We ship and sell only within the European Union — currently the EU-27 member states. Obligations that exist only for non-EU shipments (customs declarations, CN22 / CN23 forms, HS-Tarifnummer enforcement, third-country VAT zero-rating) are marked Not needed for EU-only and visually dimmed below. If we ever add Schweiz, Liechtenstein, UK, Norway or any other non-EU destination, those obligations re-activate immediately.
Overview

Eight phases, from arrival to the audit window.

Each phase has its own set of obligations and its own service stack. Use the strip below as a map; each block below has the detail.

1
Browse
before cart
 2
Checkout
cart → button
 3
Payment
~seconds
 4
Confirm
≤ minutes
 5
Invoice
same day
 6
Fulfil
≤ 1–3 days
 7
Aftermath
14d + lifetime
 8
Tax cycle
monthly / 10y
1

Customer arrives & browses

Before the cart · session-level obligations
Cookie / tracking consent banner Granular opt-in for non-essential tracking before any analytics/marketing cookie fires.
Required
MandatoryEasy
Legal basis
TTDSG § 25DSGVO Art. 6
ServiceCMP (Cookiebot / Usercentrics / Borlabs)
Build
ServicesCookiebot (~€10–30/mo), Usercentrics (~€20–50/mo), Borlabs Cookie (€59 one-time, German-made), Klaro (free, open-source self-hosted), Consentmanager (~€10–30/mo).
ApproachDrop the CMP script into <head>, configure cookie categories (necessary / statistics / marketing), wire it into GTM so non-essential tags only fire after consent. ~1–2 days including QA across browsers.
VAT-inclusive prices shown Every B2C price visible to the customer must include VAT, before they reach checkout.
Required
MandatoryTrivial
Legal basis
PAngV § 3PAngV § 4
ServiceShop platform
Build
ServicesBuilt into every shop platform. No external service needed.
ApproachStore gross price (Brutto) as the canonical value in the product table. Always render with German locale: 299,90 €. Add a small note "inkl. 19% MwSt., zzgl. Versand" near the price. <1 day.
Shipping cost & delivery time visible Before the customer can commit, they must see what shipping costs and roughly how long it takes ("Lieferzeit 1–3 Werktage" minimum).
Required
MandatoryEasy
Legal basis
PAngV § 6, § 7
ServiceShop platform
Build
ServicesStatic shipping-cost table per zone (free); for dynamic rate-shopping: Sendcloud (~€45/mo), Shipcloud, Easyship — abstract DHL/Hermes/UPS/DPD behind one API.
ApproachMinimum: a JSON shipping-rate matrix (country × weight bracket) rendered on product/cart pages with a stock delivery-time string. ~2 days. More elegant: tie it to the personalised estimator below.
Personalised delivery-date estimate (eBay-style) Show the customer "Lieferung zwischen Mo, 25. Mai und Mi, 27. Mai" calculated from their postal code, current time vs daily cutoff, and carrier transit days. Strong conversion lever, not legally required.
Required
Best practiceEasy
Legal basis
No legal basis — UX
ServiceShop platform
Build
ServicesDHL Delivery Date Estimator API (free with Geschäftskunden contract; returns predicted delivery date per Empfänger-PLZ), Sendcloud (~€45/mo, multi-carrier), Easyship, Shipcloud. Or build statically from a transit-time table.
ApproachCustomer postal code → look up zone → check current time vs daily cutoff (e.g. 14:00) → add transit days (1–3 DE, 3–7 EU, 7–14 outside EU) → skip weekends and German public holidays → render "Lieferung zwischen X und Y". Show on product page, cart, and confirmation. ~1 week including holiday calendar + edge cases (Saturday delivery, remote-area surcharges).
Legal pages reachable from every page Impressum, AGB, Widerrufsbelehrung, Datenschutzerklärung — accessible from any page, typically in the footer.
Required
MandatoryTrivial
Legal basis
TMG § 5BGB § 312dDSGVO Art. 13
ServiceIT-Rechtskanzlei texts in shop CMS
Build
ServicesIT-Rechtskanzlei subscription (~€10/mo with auto-update plugin), Trusted Shops Legal Texts, eRecht24, or write yourself with a lawyer (one-time €1–3k, never recommended for B2C).
ApproachCMS pages with the four legal texts. Optional cron that pulls IT-Rechtskanzlei's update feed daily and re-publishes. ~1 day to wire up; legal content is provided.
Grundpreis where applicable For goods sold by weight/volume, the per-unit price (e.g. €/100g). Mostly N/A for jewellery but enforce if relevant.
Required
ConditionalTrivial
Legal basis
PAngV § 4
ServiceShop platform
Build
ServicesBuilt into shop platform.
ApproachOptional grundpreis_value + grundpreis_unit fields on the product schema, rendered conditionally below the price. <1 day.
2

Checkout

From "add to cart" to clicking the order button
Cart summary with all costs before final order Product names, quantities, unit price, total, shipping, VAT shown clearly on the page that contains the "buy" button.
Required
MandatoryEasy
Legal basis
BGB § 312j Abs. 2
ServiceShop platform
Build
ServicesStandard part of any shop platform. No external service.
ApproachCart state in session (or persisted to DB for logged-in users), rendered as a summary component above the order button. Show line items + subtotal + shipping + VAT breakdown + grand total. ~3 days for a clean implementation.
"Zahlungspflichtig bestellen" button (Button-Lösung) The button that places the order must clearly state the obligation to pay — "Zahlungspflichtig bestellen", "Kostenpflichtig bestellen", or "Jetzt kaufen" are accepted. "Order" alone is not.
Required
MandatoryTrivial
Legal basis
BGB § 312j Abs. 3
ServiceShop platform
Build
ServicesNone.
ApproachA button. With the right German text. The single most-litigated CSS change in DE ecommerce — do not A/B test the wording. <1 hour.
Capture mandatory billing & shipping data Name, full address, email. Phone optional. For B2B: company name + VAT-ID if reverse charge requested.
Required
MandatoryEasy
Legal basis
BGB § 312iUStG § 14
ServiceShop platform
Build
ServicesFor address autocomplete: Google Places API (~free below 5k req/mo), HERE Geocoding, Loqate, Postcoder. For pure validation: regex + manual entry is fine.
ApproachStandard form with country-specific field rules (German PLZ = 5 digits, Austrian = 4, etc.) and per-country required fields. Postal-code → city autocomplete is a nice-to-have. ~3 days for a polished version with validation messages.
Validate VAT-ID for B2B reverse charge If a customer claims B2B status with EU VAT-ID, the ID must be validated against the EU VIES system before applying reverse charge.
Required
Mandatory (if B2B)Easy
Legal basis
UStG § 13bUStG § 18a
ServiceEU VIES API · shop integration
Build
ServicesEU VIES SOAP API (free, official, the only legally accepted source); wrappers: Vatlayer (~€10/mo for higher rate limit), Vatstack. Most ORMs/SDKs have community VIES clients.
ApproachForm input → call VIES with country code + number → store the consultation number + timestamp (proof of having checked). Cache for 24h to avoid hammering VIES. ~1 day.
Privacy notice present at data capture The customer must see (or have linked) the Datenschutzerklärung explaining what data is collected and why.
Required
MandatoryTrivial
Legal basis
DSGVO Art. 13
ServiceIT-Rechtskanzlei text in shop
Build
ServicesIT-Rechtskanzlei provides the text; no other service needed.
ApproachLinked text below the form ("Mit Absenden willigen Sie in unsere Datenschutzerklärung ein"). <1 day.
3

Payment processing

Synchronous, seconds long · happens on payment provider's hosted page
PCI-DSS compliant card handling Card data must never touch our servers. Hosted checkout / redirect to payment provider keeps PCI-DSS out of our scope.
Required
MandatoryEasy
Legal basis
PCI-DSS v4.0
ServiceStripe / PayPal / Amazon Pay (hosted)
Build
ServicesStripe (~2.9% + €0.25 per EU card), PayPal (similar), Mollie (DE-focused, ~1.8% + €0.25), Adyen (negotiated for higher volume), Klarna (BNPL), Amazon Pay.
ApproachEither Stripe Checkout (full redirect — easiest, ~1 day) or Stripe Elements (embedded iframes — better UX, ~3 days). Both keep card data off our servers, both satisfy PCI-DSS SAQ A (lowest compliance burden).
3D Secure 2 / Strong Customer Authentication (SCA) For EU cards, the customer must authenticate via 3DS2 (biometric or PIN-based) for most transactions.
Required
MandatoryTrivial
Legal basis
PSD2 (EU 2015/2366)
ServiceStripe / PayPal — built-in
Build
ServicesBuilt into Stripe, PayPal, Mollie, Adyen — every modern provider.
ApproachNothing. The payment provider runs the challenge automatically and signals success back via webhook. Don't try to implement this yourself.
Payment authorisation or capture Lock in the funds. Card payments typically auth-then-capture on ship. SEPA/Klarna may be deferred.
Required
MandatoryEasy
Legal basis
BGB § 433
ServiceStripe / PayPal / Amazon Pay
Build
ServicesStripe / PayPal / Mollie webhook endpoints.
ApproachWebhook handler for payment_intent.succeeded (Stripe) or equivalent. Verify the signature, update the order to "paid", trigger downstream events (invoice, label, confirmation email). ~2 days. Decide auth-then-capture vs immediate capture per payment method.
Match incoming bank transfers to orders For SEPA / Vorkasse / Rechnung payments where the customer wires money in: match the bank line to the open invoice and mark the order paid.
Required
Mandatory (if SEPA in use)Hard (custom)
Legal basis
GoBD Belegfunktion
ServicePayJoe
Build
ServicesPayJoe (~€20/mo, German specialist — strongly recommended); GoCardless (B2B-focused); Mollie SEPA Direct Debit. Lexoffice can ingest bank statements but doesn't do the matching logic.
ApproachUse PayJoe — this is what they do. Custom would mean: pull bank lines via PSD2 / HBCI / FinTS, parse MT940/CAMT.053 statement files, fuzzy-match by reference + amount + customer. ~2–3 weeks of fragile logic with ongoing edge-case maintenance. Not worth it at our volume.
4

Order confirmation — the contract is formed

Within minutes of payment success
Immediate order confirmation email Must arrive without undue delay (in practice: within minutes). Failure to confirm doesn't void the contract but the customer can claim Vertragsschluss didn't occur.
Required
MandatoryEasy
Legal basis
BGB § 312i Abs. 1 Nr. 1
ServiceShop · transactional email service
Build
ServicesPostmark (~€10/mo for 10k emails, best-in-class transactional deliverability), Resend ($20/mo for 50k), SendGrid, Brevo (free tier 9k/mo), AWS SES (cheapest at high volume, more setup).
ApproachWebhook on order.paid triggers email send. HTML template with order summary, customer details, legal blocks. Use MJML or Maizzle for responsive template authoring. ~3 days including template design and DKIM/SPF setup.
Confirmation contains: order summary, AGB, Widerrufsbelehrung, Datenschutz, Impressum Either as inline text or linked PDF/page. The Widerrufsbelehrung must be included as text in the email or as PDF attachment — pure link is not legally sufficient.
Required
MandatoryTrivial
Legal basis
BGB § 312fBGB § 355EGBGB Art. 246a
ServiceIT-Rechtskanzlei templates · shop email engine
Build
ServicesIT-Rechtskanzlei provides the texts.
ApproachTemplate tokens injected at send time. Either inline the full Widerrufsbelehrung text in the email (most common), or attach as PDF. Linked-only is risky — explicitly insufficient per BGH case law. ~1 day for template work.
Customer can save & reproduce contract terms The contract text must be made available to the customer in a way they can store and reproduce (typically PDF or email content).
Required
MandatoryEasy
Legal basis
BGB § 312i Abs. 1 Nr. 4
ServiceShop · email + customer account
Build
ServicesFor PDF generation: Puppeteer / Playwright (free, runs headless Chrome), pdfkit (Node.js library), wkhtmltopdf, WeasyPrint (Python).
ApproachEither: rely on the order-confirmation email itself as the "savable" form (customers can store it), or generate a PDF from the order page on demand. Most shops do both. ~2 days.
Internal storage of contract data Order + customer + product snapshot at moment of purchase, stored for retention period.
Required
MandatoryEasy
Legal basis
AO § 147GoBD
ServiceShop database + GoBD archive
Build
ServicesPostgres (free, the right default), Hetzner backups or Cloudflare R2 / Backblaze B2 for offsite snapshots.
ApproachOrders table includes a snapshot_jsonb column with the full product + customer state at order time. Never JOIN to live tables to render historical orders. Daily encrypted pg_dump to offsite storage. ~2 days for schema + backup pipeline.
5

Invoice issuance

Same day · typically alongside order confirmation
§ 14 UStG-compliant Rechnung issued Mandatory fields: full name + address of issuer and customer, Steuernummer or USt-IdNr of issuer, date of issuance, sequential gapless invoice number, quantity + description, delivery date, net amount per tax rate, applicable tax rate, tax amount per rate, total amount.
Required
MandatoryEasy via Lexoffice · Hard custom
Legal basis
UStG § 14UStG § 14a
ServiceLexoffice
Build
ServicesLexoffice API (~€20/mo, recommended), sevDesk (~€10/mo), DATEV (Steuerberater workflow), or custom PDF generation.
ApproachVia Lexoffice: POST the order on payment, Lexoffice assigns invoice number + generates PDF + retains for 10 years. ~1 week for the connector. Custom path means PDF templating (Puppeteer / WeasyPrint) + the 12+ mandatory fields + signed-immutable storage — ~2–3 weeks plus ongoing maintenance risk. Strongly recommend using Lexoffice.
Sequential, gapless invoice numbering One continuous sequence (or a clearly documented set of sequences). Gaps must be explainable or trigger audit follow-up.
Required
MandatoryTrivial via Lexoffice
Legal basis
UStG § 14 Abs. 4 Nr. 4GoBD
ServiceLexoffice
Build
ServicesLexoffice handles the sequence.
ApproachIf custom: Postgres BIGSERIAL column, never reset, never reuse. Document any controlled gaps (e.g. test invoices) in the Verfahrensdokumentation. <1 day.
For B2B over €250: full Rechnung; for ≤ €250: Kleinbetragsrechnung Simplified form allowed for small amounts (§ 33 UStDV) but most shops issue full Rechnung for everything for consistency.
Required
MandatoryTrivial
Legal basis
UStDV § 33
ServiceLexoffice
Build
ServicesLexoffice picks the correct form based on amount + customer type.
ApproachLogic branch in template; in practice always issue full Rechnung for clarity. <1 day.
E-invoice for B2B (ZUGFeRD or XRechnung) From 2025 onwards, German B2B parties must be able to receive structured e-invoices. Full enforcement progressive through 2028. Lexoffice issues ZUGFeRD natively.
Required
Phasing in 2025–2028Easy via Lexoffice · Hard custom
Legal basis
Wachstumschancengesetz 2024EN 16931
ServiceLexoffice (ZUGFeRD native)
Build
ServicesLexoffice produces ZUGFeRD natively. Custom-build libraries: mustangproject (Java, free), FNFE-MPE (Java), Phpforge ZUGFeRD (PHP). XRechnung-only is rarer but supported by same libraries.
ApproachVia Lexoffice: nothing — it ships ZUGFeRD when the receiver is flagged as e-invoice-compliant. Custom: ~2–3 weeks to wire up an EN 16931 generator and embed XML inside the PDF/A-3 container. Strongly recommend not building this.
Send invoice to customer Email attachment or download link via customer account. For B2B with active e-invoice obligation: structured format (ZUGFeRD/XRechnung).
Required
MandatoryTrivial
Legal basis
UStG § 14
ServiceLexoffice · shop email engine
Build
ServicesEmail service (Postmark / Resend); Lexoffice can also email directly from their side if preferred.
ApproachAttach the Lexoffice-generated PDF (and ZUGFeRD XML for B2B) to the order confirmation, or send as a separate "Ihre Rechnung" email. ~1 day.
6

Fulfilment

Within stated delivery time · typically 1–3 working days
Ship within stated delivery time Delivery time shown at checkout becomes a contractual commitment. Material delays without notice can give customers cancellation rights.
Required
MandatoryOperational
Legal basis
BGB § 286PAngV § 6
ServiceUs · warehouse operations
Build
ServicesNot a software problem.
ApproachInternal warehouse SLA + a dashboard alert when an order has been sitting unshipped past N hours. Process-driven, not code-driven.
Generate compliant shipping label For domestic and EU shipments. DHL API integration generates labels with tracking.
Required
MandatoryMedium
Legal basis
Carrier T&Cs
ServiceDHL · Portal/shop integration
Build
ServicesDHL Geschäftskundenversand API (requires Geschäftskunden contract; native), DHL Parcel DE API, Sendcloud (~€45/mo, abstracts multi-carrier), Shipcloud, multi-carrier Easyship. Hermes / DPD / UPS have direct APIs too.
ApproachAPI call passes weight + dimensions + addresses → returns label PDF + tracking number. DHL API is well-documented and stable; Sendcloud is the easiest if multi-carrier matters. ~1–2 weeks first carrier, +3 days each additional. Print the label, attach to package.
Customs declaration for non-EU shipments CN22 for low-value packages, CN23 for higher value. Includes HS-Tarifnummer (customs tariff code), declared value, weight, country of origin.
Required
Mandatory (if non-EU)Medium
Legal basis
UZK (EU Customs Code)Weltpostverein
ServiceDHL API · Portal data
Build
ServicesDHL API supports customs forms natively; Sendcloud handles too. For HS-code lookups: WCO Trade Tools (free), TARIC consultation (EU customs tariff browser).
ApproachPer shipment: collect HS-Tarifnummer (stored on product), declared value (= sale price), country of origin (Estonia for Gaura items), weight. Pass to DHL API which generates the customs form. ~1 week including HS-code population for the existing catalogue.
Send tracking info to customer Email with carrier and tracking number, ideally with link.
Required
Best practiceEasy
Legal basis
Industry standard
ServiceShop email · DHL webhook
Build
ServicesEmail service + DHL Push API for status events (free), Sendcloud notifications, AfterShip ($9/mo for branded tracking pages with multi-carrier).
ApproachWhen a label is generated, send "Ihr Paket ist auf dem Weg" email with tracking link. Optional: poll DHL Push for delivery status, send "Lieferung heute zugestellt" follow-up. ~2 days basic, ~1 week for branded tracking page.
Update marketplace with shipment status For marketplace orders (Otto, Amazon), confirm shipment + tracking back to the marketplace within their SLA.
Required
Mandatory (marketplaces)Medium via Magnalister
Legal basis
Marketplace T&Cs
ServiceMagnalister
Build
ServicesMagnalister (handles all marketplaces). Direct: Amazon SP-API (Hard — months), Otto Market API (Hard — months).
ApproachOrder shipped → POST shipment event to Magnalister → it pushes to each marketplace per their format/SLA. ~1 week to wire Magnalister into our shop's event stream. Direct integration would be 2–4 months per marketplace and is not worth it.
7

Aftermath — the 14-day window and beyond

14-day Widerruf + ongoing customer rights
14-day Widerrufsrecht (cancellation right) For B2C distance contracts: customer can cancel within 14 days of receipt without giving a reason. Counter starts at receipt of the last item.
Required
MandatoryEasy
Legal basis
BGB § 355BGB § 356
ServiceShop process · IT-Rechtskanzlei text
Build
ServicesDHL Retoure API (return labels with prepaid postage), Sendcloud Returns Portal, AfterShip Returns ($23/mo for branded portal). IT-Rechtskanzlei provides the Widerrufsformular template.
ApproachSelf-service portal: customer enters order # + email → generates DHL return label → order transitions to "return requested" state. Email with label PDF attached. ~1 week.
Refund within 14 days of return receipt Once the returned goods arrive (or tracking shows shipment), refund full payment via the same payment method within 14 days.
Required
MandatoryEasy
Legal basis
BGB § 357
ServiceStripe / PayPal refund · Lexoffice credit note
Build
ServicesStripe Refunds API (free, single call), PayPal Refunds API, Amazon Pay Refund.
ApproachWhen return is approved + goods received: API call to refund the payment + trigger Lexoffice credit note. Update order state to "refunded". ~3 days including admin UI for approval workflow.
Issue credit note (Stornorechnung) for refunds Refunded invoice must be matched by a Stornorechnung in the bookkeeping — invoice itself is not deleted (GoBD: immutability).
Required
MandatoryTrivial via Lexoffice
Legal basis
UStG § 14GoBD
ServiceLexoffice
Build
ServicesLexoffice handles natively.
ApproachPOST credit-note voucher to Lexoffice with reference to original invoice ID. Lexoffice issues the Stornorechnung with its own sequential number. <1 day.
Handle customer rights requests (DSGVO Art. 15–22) Customer can request: data access, correction, deletion, portability, restriction. Must respond within one month (extendable to three with justification).
Required
MandatoryMedium
Legal basis
DSGVO Art. 15–22
ServiceUs · supported by shop + Lexoffice data export
Build
ServicesNo direct SaaS — build the workflow. Tools that simplify ongoing privacy posture: Plausible / SimpleAnalytics (privacy-first analytics that don't trigger most DSGVO requests).
ApproachData export endpoint: query every table for the given customer's email/ID → produce JSON / CSV bundle (~3 days). "Deletion" workflow: anonymise PII fields on customer record (replace name/email with a hash) while keeping order records intact for 10-year GoBD retention (~3 days). Customer-facing request form at /datenschutz/anfrage. Internal SLA tracker. ~2 weeks total.
Customer service obligations (Gewährleistung) 2-year warranty for defects in B2C goods. Replacement/repair/refund obligations under the German statutory warranty regime.
Required
MandatoryOperational
Legal basis
BGB § 437BGB § 438
ServiceUs · warehouse + customer service
Build
ServicesNot a software problem — but a helpdesk helps: Front (~€19/user/mo), Help Scout (~€20/user/mo), Crisp (free tier), or just email with a shared mailbox.
ApproachProcess-driven: ticket workflow + repair/replace/refund decision tree + budget for warehouse handling. The shop just needs an admin view showing past orders per customer.
Review request (optional) Post-delivery, invite the customer to leave a review. Must comply with DSGVO consent — opt-in or legitimate interest with clear unsubscribe.
Required
Optional / MarketingEasy
Legal basis
DSGVO Art. 6UWG (anti-spam)
ServiceShopvote · shop email engine
Build
ServicesShopvote (~€20/mo, already in stack), Trusted Shops, Trustpilot, Judge.me, Yotpo.
ApproachTriggered email N days after delivery confirmation (typically 7–14) → links to Shopvote review form. Include opt-out per UWG. ~2 days to wire the trigger and template.
8

Ongoing tax & compliance cycle

Monthly / quarterly / annual · 10-year retention
Monthly or quarterly USt-Voranmeldung VAT pre-declaration submitted via the ELSTER portal. Monthly if previous-year VAT > €7,500; quarterly otherwise. Annual return submitted by 31 July of the following year.
Required
MandatoryTrivial via Lexoffice
Legal basis
UStG § 18AO § 149
ServiceLexoffice → ELSTER · Steuerberater
Build
ServicesLexoffice (one-click submission to ELSTER), sevDesk, DATEV (Steuerberater route). Direct ELSTER ERiC API exists but is complex.
ApproachDon't build. Lexoffice's Voranmeldung is mature and the Steuerberater either submits or reviews before submission. Never integrate directly with ELSTER — pure technical debt.
Quarterly OSS-Meldung (cross-border B2C) If EU-wide B2C distance sales exceed €10,000/year, the OSS scheme applies. Quarterly report filed via the BZSt portal.
Required
Mandatory (we exceed threshold)Trivial via Lexoffice
Legal basis
UStG § 18j
ServiceLexoffice → BZSt · Steuerberater
Build
ServicesLexoffice provides the OSS export with all required columns (transaction date, customer country, net amount, VAT rate, VAT amount).
ApproachQuarterly: export from Lexoffice → upload to BZSt portal (or Steuerberater submits). ~30 min of work per quarter. Don't build automation here — the volume is too low.
Verpackungsgesetz Mengenmeldung LUCID registration and annual packaging-quantities report.
Required
MandatoryOperational
Legal basis
VerpackG § 9, § 11
ServiceUs · LUCID portal
Build
ServicesLUCID portal (registration is free), system participation (Duales System / Der Grüne Punkt / Reclay): ~€100–300/year for our volume.
ApproachTrack packaging weight per material (paper / plastic / glass / metal) per shipment in shop DB — small schema change. Annual export → upload to LUCID. ~3 days for the tracking schema.
10-year retention of tax-relevant data Invoices, orders, customer master data (as tied to orders), product data at moment of sale, accounting records — kept readable and exportable for 10 years from end of fiscal year.
Required
MandatoryEasy
Legal basis
AO § 147HGB § 257GoBD
ServiceLexoffice · shop DB · archived Gambio DB
Build
ServicesLexoffice retains invoices and vouchers for 10 years automatically. For our shop DB: Cloudflare R2 (~€0.015/GB/mo), Backblaze B2 (~€0.005/GB/mo), AWS S3 Glacier (~€0.004/GB/mo for long-term).
ApproachDaily encrypted pg_dump to R2/B2 with object-lock for immutability. Retention policy: 11 years to be safe. Read-only Gambio DB archive in a Docker container for cutover-era data. ~3 days setup + documentation.
GoBD-compliant audit access (Z3 export) On Finanzamt request (Betriebsprüfung), produce structured tax-relevant data in a machine-readable format (Z3 / IDEA).
Required
Mandatory on requestTrivial via Lexoffice
Legal basis
AO § 147 Abs. 6GoBD
ServiceLexoffice (Z3 export)
Build
ServicesLexoffice has Z3 / IDEA export built in. Steuerberater handles the actual hand-off to the Betriebsprüfer.
ApproachDon't build. Use Lexoffice's export. The auditor receives a structured archive they can ingest into IDEA (their auditing software).
Verfahrensdokumentation kept current Written documentation of how the shop, accounting connector, invoice numbering, archive, and DSGVO processes work — updated whenever the system changes.
Required
MandatoryEasy initial · ongoing
Legal basis
GoBD Rz. 151–155
ServiceUs + Steuerberater · live document
Build
ServicesNo SaaS — written by us with the Steuerberater. Templates available from DStV, IHK, and GoBD guidance documents.
ApproachMarkdown document in the workspace, version-controlled (git). Cowork drafts; Steuerberater reviews and signs. Update on every major architecture change. ~2–3 days initial draft + ~1 day per significant change. Don't skip — its absence is the single most common GoBD audit finding.
Special cases

B2B, marketplaces, and the audit window.

Three flows that branch off the main eight-phase loop and deserve their own short summary.

B2B differences

When the customer is a business with a verified EU VAT-ID, several phases change subtly.

  • Phase 2 · Capture and validate VAT-ID via EU VIES before applying reverse charge.
  • Phase 3 · Common to use Rechnung-payment (pay-on-invoice) rather than cards; longer payment terms.
  • Phase 5 · Reverse-charge invoice — no VAT shown, with the note "Steuerschuldnerschaft des Leistungsempfängers" (Reverse Charge).
  • Phase 5 · From 2025 onwards, B2B parties must be able to receive structured e-invoices (ZUGFeRD / XRechnung). Mandatory issuance phased through 2028.
  • Phase 7 · No 14-day Widerrufsrecht for B2B distance contracts.

Marketplace orders (Otto, Amazon)

When an order originates from a marketplace, several phases happen *on the marketplace*, not on our shop.

  • Phase 1–4 · Browse, checkout, payment, confirmation all happen on the marketplace. We see the order only after it's confirmed.
  • Phase 5 · We still issue our own invoice. Otto requires a specific format → handled by Easyinvoice (or migrates to Lexoffice/Shopify-app in Path 3). Amazon's invoice format is more flexible.
  • Phase 6 · Marketplace expects shipment confirmation + tracking pushed back within their SLA (typically 1–3 days).
  • Phase 7 · Customer service typically routed through marketplace first; returns handled per marketplace policy.
  • All routed via Magnalister — that's the single integration that translates our order/shipment/inventory events to and from each marketplace.

The 10-year audit window

Every order generates artefacts that must survive for ten years from the end of the fiscal year in which the order occurred.

  • Invoice · immutable PDF (or structured e-invoice) — Lexoffice retains.
  • Order record · full snapshot of what the customer bought, including product master data at the moment of sale — shop DB + GoBD archive.
  • Payment record · transaction ID, method, amount, date — Stripe + Lexoffice.
  • Shipping record · carrier label, tracking, delivery confirmation — DHL records + Lexoffice voucher.
  • Customer master at time of sale · captured in Lexoffice and shop DB.
  • Communication · order confirmation email retained.
  • Format requirement · all of the above must be readable and exportable in a machine-readable form (Z3 / IDEA) on Finanzamt request.
Service coverage

Which service covers what.

The same eight phases, viewed inversely — what each service in our stack is responsible for. This is the canonical answer to "what must we have?"

Shop platform
Gambio today · Custom or Shopify later
Phase 1–4 customer-facing: price display, shipping cost display, cart, "Zahlungspflichtig" button, address capture, order confirmation email, contract-data storage. Phase 6: generate shipping labels via DHL. Phase 7: return flow trigger, customer account self-service.
CMP (Cookiebot / Usercentrics)
Optional — could self-host an open-source CMP
Phase 1: TTDSG-compliant consent banner. Records consent state, blocks non-essential scripts until opt-in.
IT-Rechtskanzlei
Subscription · ~€10/mo
Phase 1: Impressum, AGB, Widerrufsbelehrung, Datenschutzerklärung — kept up to date as law changes. Phase 4: Widerrufsbelehrung text used in order confirmation email. Phase 7: Widerrufsformular template.
Stripe / PayPal / Amazon Pay
Payment provider · hosted checkout
Phase 3: PCI-DSS compliance, 3DS2 / SCA, payment capture, refund processing. Optional: Stripe Tax for calculation (not recommended for us — Lexoffice already covers it).
PayJoe
Subscription · ~€20/mo
Phase 3: Match incoming SEPA / bank-transfer line items to open invoices. Critical for Vorkasse and Rechnung payment methods.
Lexoffice
The legal source of truth · ~€20/mo
Phase 5: § 14 UStG-compliant invoice issuance, sequential numbering, ZUGFeRD output for B2B, send to customer. Phase 7: Stornorechnung on refunds, voucher matching. Phase 8: USt-Voranmeldung data, OSS reporting data, Z3 audit export, DATEV hand-off to Steuerberater, 10-year retention.
DHL / Deutsche Post
Carrier · usage-based
Phase 6: Shipping labels, tracking, customs declarations (CN22/CN23) for non-EU. Records retained by DHL — we reference tracking numbers in our shop DB.
Magnalister
Marketplace hub · ~€80/mo
Phase 1–4 (marketplace orders): Bridges marketplace lifecycle to our shop. Phase 6: Pushes shipment + tracking back to Otto/Amazon. Phase 7: Routes marketplace return events.
Shopvote
Reviews · ~€20/mo
Phase 1: Embed widget showing trust seal. Phase 7: Send post-purchase review request, host customer reviews, feed AggregateRating schema for Google snippets.
Steuerberater
External professional · annual + advice
Phase 8: Reviews and signs off USt-Voranmeldungen and OSS-Meldungen, files the annual UStG-Erklärung and income/corporate tax, reviews Verfahrensdokumentation, prepares for Betriebsprüfung. Crucial across all phases: the legal authority on what is and isn't compliant — Cowork drafts, the Steuerberater signs.
LUCID
Zentrale Stelle Verpackungsregister
Phase 8: Annual packaging-quantities report under Verpackungsgesetz. Separate from the shop flow but part of total compliance picture.
Us (warehouse + customer service)
Human operations
Phase 6: physical fulfilment. Phase 7: Gewährleistung handling, return inspection, customer service, DSGVO request response. All phases: business decisions, oversight, the actual signing of the Verfahrensdokumentation.
What this means for the new architecture

Six things the new shop must do — in any path.

01 · Talk to Lexoffice on every paid order

The order-paid event must POST to Lexoffice's API to trigger invoice issuance. Same in Path 1 (Sticky ERP today, replaced later), Path 2 (custom connector), Path 3 (Eshop Guide app).

02 · Capture the contract snapshot

At order time, freeze product data, prices, tax rate, customer master. These can't change retroactively — GoBD immutability. The shop DB schema must reflect this snapshot, not point at live data.

03 · Render the "Zahlungspflichtig" button correctly

The single most-litigated detail in DE ecommerce. Cart summary + correctly-worded button + final review = non-negotiable. Cannot be skipped or A/B-tested.

04 · Issue the order confirmation email with all four legal texts

Widerrufsbelehrung, AGB, Datenschutzerklärung, Impressum — included as text or PDF. The shop's email engine handles this; IT-Rechtskanzlei provides the texts. No exceptions.

05 · Build the Verfahrensdokumentation alongside the code

As we change the architecture, the Verfahrensdokumentation must be updated. The Steuerberater signs it before any cutover happens. Cowork drafts the update; the human authority signs.

06 · Preserve the 10-year retention

Existing Gambio data archives read-only; new shop data accumulates in Lexoffice + shop DB; both must remain queryable on Finanzamt request through 2036 for any orders placed in 2026. This shapes our backup strategy from day one.