German accounting has a handover problem that ERPNext does not solve out of the box. Your Steuerberater works in DATEV, expects a monthly EXTF buchungsstapel with the exact header line, the exact column order, Windows-1252 encoding and semicolon separators, plus a matching Belege archive so every booking has its document. ERPNext gives you an accurate General Ledger, a Chart of Accounts you designed yourself, and CSV/Excel exports from the report view — none of which DATEV will accept. The usual result is a bookkeeper re-keying or hand-massaging spreadsheets every month, corrections that nobody can trace back to the originating Sales Invoice, and an advisor charging for cleanup work that should never have existed.

What we build is a proper Frappe app — its own repository, its own module, installable with bench get-app and bench --site … install-app — not a pile of loose customizations that vanish on the next migration. At its centre is a DATEV Export DocType that takes a company, a fiscal period and a target format, reads submitted GL Entries through the Frappe ORM, and writes a DATEV-conformant file: the EXTF header carrying Berater, Mandant, WJ-Beginn, Sachkontenlänge and the period bounds, then one row per booking with Umsatz, Soll/Haben-Kennzeichen, Konto, Gegenkonto, BU-Schlüssel, Belegdatum, Belegfeld 1 and Buchungstext, encoded and quoted the way DATEV's import expects. Amounts are always written positive with an explicit S/H indicator, because a signed amount is the single most common reason an import is rejected.

Account mapping is the part that decides whether the export is usable. A DATEV Account Mapping DocType maps each ERPNext Account onto its SKR03 or SKR04 counterpart, with per-mapping tax handling so that a 19% domestic sale, a 7% reduced-rate sale, a reverse-charge EU service and a non-taxable transfer each carry the correct BU-Schlüssel rather than being flattened into one bucket. Debtor and creditor accounts are resolved to Personenkonten from a configurable numeric range, so a Customer or Supplier lands on a stable ledger number instead of a name string. Mappings are validated before an export ever runs: a scheduled job and a pre-export check both surface unmapped accounts, missing tax keys and out-of-range personal accounts as a blocking report, so you find the gap while you can still fix it rather than after your advisor has bounced the file.

Around the export sits the workflow your advisor's month actually follows. Belege export bundles the File attachments behind each booking — the Sales Invoice PDF, the scanned Purchase Invoice — into a DATEV Belegtransfer package with a document.xml index that links each document back to its booking, so the advisor sees the paperwork next to the row. A DATEV Export Period record locks a period once it has been handed over: a hooks.py doc event on Journal Entry, Sales Invoice, Purchase Invoice and Payment Entry refuses submission or cancellation into a locked period, which is what stops a "small correction" from silently invalidating a file already sitting in your advisor's system. When something genuinely must change, a controlled re-export produces a new numbered Stapel for that period, records what changed against the prior export, and leaves an audit trail on the DATEV Export document instead of overwriting history. Permissions are wired to role profiles — an Accounts User can prepare and review, only an Accounts Manager can lock a period or authorise a re-export — and a whitelisted method plus the standard Frappe REST API let a scheduler event or an external process trigger and fetch the monthly export unattended.

Delivery is build-to-order. You request a quotation, we run a scoping call to confirm your SKR variant, your tax scenarios, whether Belege transfer is in play and what your advisor's Berater/Mandant numbers are, and we write that into a fixed scope. Typical delivery is 2-4 weeks from confirmed scope, targeting your Frappe/ERPNext version (v15 or v16). We build against a copy of your Chart of Accounts, hand you the app on a staging site for UAT with a real month of your own data, produce a sample file your Steuerberater can test-import before go-live, then install on production with a rollback path. You receive the full source in a git repository you own, install and configuration documentation, a user guide, a training session, and a post-go-live support window for defects.