German SMB Operations: Lexoffice, Xentral, and the GoBD Compliance Gap
DATEV export is table stakes. But GoBD compliance requires operations-level audit trails — and most German tools miss this.
The Problem
You run a German e-commerce business. Your accountant uses Lexoffice or sevDesk to generate the DATEV export at year-end. That file is perfect for tax filing — every invoice, every payment, every transaction is there.
But when the Finanzamt audits your warehouse operations, the story breaks.
“Where did the 500 units of SKU-12345 go on March 12th? Who moved them? Why?”
Your operations tool — Xentral, JTL-Software, or Billbee — shows the current stock count. It does not show the per-movement audit trail that GoBD (Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff) requires for operational traceability.
The accountant’s DATEV export is pristine. The warehouse operations record is incomplete.
This is the GoBD compliance gap — and it is why German SMBs face unexpected audit findings when operations data is incomplete.
What GoBD Actually Requires
GoBD is often misunderstood as “only accounting compliance.” That is incorrect. GoBD applies to all electronic records that affect your financial statements — including inventory movements, stock adjustments, and operational workflows.
The GoBD requirements for operations-level records1:
| Requirement | What it means in practice |
|---|---|
| Verarbeitungsprotokollierung (processing documentation) | Every inventory movement must record who, when, and why |
| Nachvollziehbarkeit (traceability) | You must reconstruct the complete history of a stock item |
| Unveränderbarkeit (immutability) | Audit records must be append-only; editing requires a correction entry |
| Zugriffskontrolle (access control) | Only authorized users can adjust stock records |
| Aufbewahrung (retention) | Records must be retained for 10 years |
Most German accounting tools (Lexoffice, sevDesk, FastBill) handle these requirements for invoices and payments. That is why their DATEV exports work.
Most German operations tools (Xentral, JTL, Billbee) are commonly configured around current stock levels rather than a complete, per-movement movement history. If your workflow does not explicitly record one, the audit trail for inventory is thinner than what GoBD expects.
Why Lexoffice and sevDesk Fall Short
Lexoffice, sevDesk, and FastBill are excellent at what they do: German accounting with DATEV export. Their features are well-designed for invoicing, expense tracking, and VAT compliance.
But they are not operations systems.
| Tool | Strength | Gap for operations |
|---|---|---|
| Lexoffice | DATEV export, German invoicing, VAT compliance | No inventory movements ledger, no warehouse UI |
| sevDesk | Document management, German tax rules | Limited inventory tracking, no per-movement audit trail |
| FastBill | German invoicing templates, easy setup | No warehouse operations, stock adjustments are manual |
If you use Lexoffice for accounting and Xentral for operations, you have two separate systems. The DATEV export from Lexoffice is complete. The operations audit trail from Xentral is incomplete. When the Finanzamt asks “who moved what when,” Xentral cannot answer.
Why Xentral, JTL, and Billbee Fall Short
Xentral, JTL-Software, and Billbee are e-commerce ERPs designed for German merchants. They connect to Shopify, Amazon, and Otto. They handle order processing, shipping labels, and stock management.
But they are cloud-dependent, multi-tenant systems with limitations that matter for GoBD-style operations auditability:
1. No per-movement audit trail
Depending on how Xentral is configured, stock adjustments may be recorded as level changes rather than a rich per-movement history. If your setup does not capture who adjusted what and why, an audit question like “who adjusted this stock and why?” can be hard to answer from the system alone.
2. Multi-tenant data architecture
Your data lives in a shared database alongside other merchants. Some German auditors and Steuerberater prefer operations data to be isolatable on your own infrastructure; multi-tenant SaaS makes that harder to demonstrate.
3. Cloud dependency
German warehouses in industrial zones often have unreliable internet. When connectivity drops, cloud-based ERPs stop working. Your warehouse team cannot receive shipments, adjust stock, or pick orders offline.
4. Vendor lock-in
Exporting your complete operations data from Xentral is possible, but the process is opaque: you depend on their export formats and schedule rather than direct access to the live database.
The Offline Warehouse Problem in Germany
This is not theoretical. German logistics hubs — from München-Nord to Hamburg-Harburg — have warehouses in industrial zones with poor cellular coverage and spotty Wi-Fi.
Consider a typical scenario, assembled from situations German warehouse teams describe regularly. A warehouse in an industrial zone runs on a single DSL line. During peak receiving hours (8:00–11:00 AM), several devices connecting to a cloud ERP cause timeouts. Stock adjustments fail. The team reverts to paper lists and manual Excel updates.
A week later, the paper records are entered into the system. But the audit trail is now broken: the record shows entries made days later by a different employee — not who physically received the shipment, or when.
This is the offline warehouse problem. Cloud-based ERPs assume reliable connectivity. German industrial zones do not guarantee it.
The Solution: Offline-First Operations with Per-Movement Audit
The fix is an operations system that:
- Tracks every inventory movement with a complete audit record (who, when, why, what changed)
- Works offline by queueing mutations locally and syncing when connectivity returns
- Stores data on your infrastructure (single-tenant German VPS for data sovereignty)
- Exports the complete audit trail in a format that satisfies GoBD requirements
This is exactly what ak-ops provides:
Offline warehouse operation
↓
Mutation queued in browser localStorage
↓
No connectivity? Continue working.
↓
Connectivity returns → conflict-aware sync to server
↓
Server records movement in audit table:
- movement_id: M-2026-03-15-0847
- user_id: U-123 (Hans Müller)
- timestamp: 2026-03-15 08:47:23
- movement_type: "receipt"
- product_id: P-789
- quantity_change: +50
- reference: "PO-4567 from Supplier ABC"
- source_ip: 192.168.1.42This audit record is immutable. It is stored in the movements ledger and never deleted. The complete history of every stock adjustment is queryable and exportable.
How This Supports GoBD Requirements
GoBD compliance is ultimately organizational — it depends on your processes and your Steuerberater’s sign-off, not on software alone. What an operations platform can do is supply the technical foundation:
| GoBD Requirement | How ak-ops supports it |
|---|---|
| Verarbeitungsprotokollierung | Every movement records user, timestamp, type, and reference |
| Nachvollziehbarkeit | Query the movements ledger by product, date, or user to reconstruct history |
| Unveränderbarkeit | Movements are append-only; corrections require new movement entries |
| Zugriffskontrolle | Role-based access; only authorized users can create stock adjustments |
| Aufbewahrung | SQLite database exports include complete 10-year history |
When the Finanzamt asks “who moved what when,” the answer is one query against the movements ledger — every receipt, every sale, every adjustment, every transfer, reconstructable for any product and period.
Data Sovereignty: Your Data, Your German VPS
GoBD and GDPR intersect on data sovereignty. For German businesses, storing operations data on foreign servers adds complexity to audits and compliance.
ak-ops is single-tenant. You deploy it on your own German VPS (Hetzner, Strato, or any German provider). The SQLite file is directly accessible. You can export backups, run queries, or migrate the entire system without asking a vendor for permission.
This is the pattern behind the demo at demo.kamensky.dev: a complete operations history — who, when, why — recorded as append-only movement entries, exportable at any time. Before any migration decision, a proper audit inspects what your current system can actually reconstruct.
The Cost Comparison
| Approach | Monthly cost | GoBD audit trail | Offline warehouse | Data sovereignty |
|---|---|---|---|---|
| Lexoffice + Xentral | €89–249/mo combined | Partial (Xentral) | No | Multi-tenant |
| sevDesk + Billbee | €49–149/mo combined | None | No | Multi-tenant |
| weclapp | €399+/mo | Yes, but overkill | Limited | Multi-tenant |
| ak-ops (self-hosted) | €4–6/mo (VPS) | Complete (movements ledger) | Yes (conflict-aware sync) | Single-tenant |
The self-hosted approach replaces the operations layer (Xentral, JTL, Billbee) and integrates with your existing accounting tool (Lexoffice, sevDesk). You keep the DATEV export. You gain the missing audit trail.
When You Need More Than Basic Compliance
GoBD compliance is the baseline. But growing German operations hit the next layer:
- Multi-location warehouses: Receive in Frankfurt, ship from München. The movements ledger must track location transfers.
- Serial number tracking: High-value items require serial-level audit records. The movements ledger supports this.
- Supplier quality cases: A shipment arrives damaged. You need to record the quality case, document the claim, and track the credit. ak-ops has a built-in quality cases workflow.
Each of these is an extension of the same pattern: record the movement, record the user, record the timestamp, and never delete the record.
TL;DR
| Concern | Lexoffice/sevDesk | Xentral/JTL/Billbee | ak-ops |
|---|---|---|---|
| DATEV export | ✅ Complete | ❌ No | Use with Lexoffice |
| GoBD audit trail | ❌ No operations | ⚠️ Partial | ✅ Complete (movements ledger) |
| Offline warehouse | ❌ Cloud-only | ❌ Cloud-only | ✅ Conflict-aware offline sync |
| Data sovereignty | Multi-tenant | Multi-tenant | Single-tenant (your VPS) |
| German localization | ✅ Native | ✅ Native | ✅ Native (en/de) |
| Monthly cost | €29–89 | €49–249 | €4–6 (infrastructure only) |
If you run a German e-commerce or warehouse operation and your current tools cannot answer “who moved what when,” you have a GoBD compliance gap. The fix is not another subscription — it is an operations system that records every movement and stores the data on your infrastructure.
If your German operations toolset cannot answer “who moved what when,” book a 20-minute fit call — I will assess your GoBD exposure. For how offline-first operations actually work in practice, see AppSheet Offline Mode vs. a Tailored Platform, and for the spreadsheet failure modes behind most German warehouse chaos, see Your Inventory Spreadsheet Will Break at 10k SKUs.
Sources
Footnotes
-
GoBD (Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern), BMF, 2024. Official guidance applies to all electronic business records, not just accounting. ↩