GoBD Compliance in App Development: What We Learned Building ladekosten.app
Audit-proof data storage in a mobile app sounds like an enterprise project. We built it into a charging cost tracker for EVs - and learned more about German regulatory requirements than we bargained for.

Anyone can build a charging app. A GoBD-compliant one is a different story.
When we started ladekosten.app, the idea was simple: help freelancers and business owners document EV home charging costs for tax deductions. Sounded like a weekend project. It wasn't.
Because the moment an app processes tax-relevant data in Germany, the GoBD kicks in - the "Principles for the Proper Management and Storage of Books, Records, and Documents in Electronic Form." And those principles change everything about how you build software.
What GoBD demands from an app
Most developers have heard of GoBD in passing. "Something about data retention." In reality, it defines six principles that directly impact your app architecture:
Traceability. Every booking must be traceable from creation to evaluation without gaps. In an app, that means every charging entry needs a complete audit trail.
Verifiability. A qualified third party must be able to review the data in a reasonable time. Your data structure needs to be not just functional - it needs to be readable.
Immutability. This is where most app projects fail. Once recorded, data must not be modified. No updates to existing records. No "quick corrections."
Completeness. All business transactions must be recorded without gaps. No missing entries, no holes in the numbering sequence.
Accuracy. Records must reflect the actual transaction. Sounds obvious, but it has massive implications for UX design.
Timeliness. Entries must be recorded promptly. Not next month. Not "when I get around to it."
How we solved it technically
Immutability without a cloud
The biggest challenge: ladekosten.app works 100% offline. No cloud, no servers, all data stays on the device. This was a deliberate choice - privacy is non-negotiable for our users.
But how do you guarantee immutability without a central authority?
Our solution: every charging entry is written once and never overwritten. Corrections create a new record that references the original. This produces a complete change history - similar to a blockchain, without the overhead.
Sounds simple. The implementation wasn't. Every UI interaction that intuitively looks like "edit" is actually "create new with reference" in the backend. The user sees an edit button. The system creates a correction entry.
DATEV export: bridging the gap to accountants
A GoBD-compliant app is useless if the data can't reach the accountant. So we built a DATEV CSV export.
DATEV CSV sounds harmless. It isn't. The format has quirks that are nowhere properly documented. Field lengths, character encoding, mandatory fields that are optional depending on context - it took us three iterations before the export reliably imported into every DATEV version.
Lesson learned: If your app needs to interface with accountants or bookkeeping systems, budget as much time for the export as for the core feature. At minimum.
The 34-cent flat rate and its edge cases
For home charging of company EVs, there's a flat rate: 34 cents per kWh. The tax office accepts this without individual proof - as long as the documentation is solid.
Sounds easy? It is. Until you discover the edge cases:
- What happens when the electricity tariff changes mid-month?
- How do you document mixed charging sessions (personal and business)?
- What if the wallbox doesn't pass clean kWh data?
Each of these cases requires a decision: solve it automatically or ask the user? Too much automation and you risk incorrect bookings. Too many prompts and the app becomes unusable.
We chose a middle ground: capture automatically, confirm manually. The app suggests, the user approves. This preserves accuracy without destroying the UX.
What this means for your app project
You don't need to build a charging app to benefit from our experience. These principles apply to any app that handles regulated data:
1. Compliance is architecture, not a feature
GoBD compliance can't be bolted on like dark mode. Data immutability must be baked into the database structure from day one. Retrofitting it means essentially rewriting the app.
In practice: Before you write a single line of code, clarify the regulatory requirements. Talk to a tax advisor. Read the relevant regulatory guidance. Yes, it's tedious. Yes, it's necessary.
2. Offline-first and compliance aren't mutually exclusive
"For GoBD you need a cloud solution." We heard this a lot. It's wrong.
ladekosten.app proves that audit-proof data storage works locally. The key is a clean data model with append-only logic and cryptographic checksums. Not rocket science - but not something you throw together on a Friday afternoon either.
3. UX and compliance are a negotiation
The biggest danger with regulated apps: you build for the auditor, not the user. Every required field, every confirmation dialog, every extra step costs you users.
With ladekosten.app, we reworked every compliance flow three times. Not to weaken the requirements, but to make them invisible. Users should be documenting charging costs - not feeling like they're filing a tax return.
4. Test with real data and real accountants
Unit tests aren't enough. We tested the DATEV export with five different accounting firms. Each had a different DATEV version, different import workflows, different expectations for the format.
Only after all five confirmed that the import worked flawlessly did we release the feature. That cost an extra two weeks. Every minute was worth it.
The honest bottom line
ladekosten.app took three times longer than originally planned. Not because of the core feature - tracking charging costs is technically trivial. Because of compliance.
Was it worth it? Absolutely. The app now has over a thousand active users who trust that their data will hold up in a tax audit. That trust can't be retrofitted.
And that's the lesson: if you're building an app that handles regulated data, don't plan compliance as phase three. Plan it as phase zero.
Planning an app with regulatory requirements? Talk to us - we'll share our experience from ladekosten.app and give you an honest assessment of the compliance challenges ahead.
Subscribe to Newsletter
Get monthly practical tips on digitalization
We respect your privacy. Unsubscribe anytime.