xhub.io
A Digital Service by BeeBack UG
ServicesSolutionsAI StrategyProductsBlogAboutContact
Back to Blog
App Development

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.

Author
Patrick Jerominek
Published
February 19, 2026
Read time
6 min read
GoBD Compliance in App Development: What We Learned Building ladekosten.app

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.

Tags
#GoBD#App Development#Compliance#E-Mobility#ladekosten.app
Share this article

Subscribe to Newsletter

Get monthly practical tips on digitalization

We respect your privacy. Unsubscribe anytime.

Contents

  • Anyone can build a charging app. A GoBD-compliant one is a different story.
  • What GoBD demands from an app
  • How we solved it technically
  • Immutability without a cloud
  • DATEV export: bridging the gap to accountants
  • The 34-cent flat rate and its edge cases
  • What this means for your app project
  • 1. Compliance is architecture, not a feature
  • 2. Offline-first and compliance aren't mutually exclusive
  • 3. UX and compliance are a negotiation
  • 4. Test with real data and real accountants
  • The honest bottom line
xhub.io

25 years of digital innovation excellence

in𝕏⌗

Our Services

  • AI Strategy
  • Custom Software Development
  • SaaS & Platform Solutions
  • Strategic IT Consulting
  • Digital Transformation
  • Cloud Migration & DevOps

Products

  • invoice.xhub.io
  • invoice-api.xhub.io
  • tempus.xhub.io
  • cv.xhub.io

Company

  • About Us
  • Blog
  • Contact

Legal

  • Legal Notice
  • Privacy Policy
  • Terms of Service

© 2026 xhub.io is a Digital Service by BeeBack UG. All rights reserved.