Export Invoices in DATEV Format

Most accounting software exports come with a one-click "Export to QuickBooks" or "Send to Xero" button. DATEV does not work that way. The German market has its own format, its own field names, its own encoding requirement, and a Steuerberater in the middle who expects to receive a correctly structured file every month. Get it right and the handoff is frictionless. Get it wrong and the tax advisor spends a billing hour fixing the import before they can do any actual work.

This guide covers who uses DATEV, what the format actually consists of, which fields matter and why, how German charts of accounts affect every account number in your export, the attachment workflow for digital vouchers, and the pitfalls that reliably break first attempts.

Who uses DATEV and why it dominates the German-speaking market

DATEV is a cooperative software company founded in 1966, owned by its member Steuerberater (tax advisors) and Wirtschaftspruefer (auditors). It is not a general-purpose accounting platform marketed to business owners. It is the professional tool used by the tax advisory community in Germany, Austria, and Switzerland, and most German SMBs never interact with it directly.

The practical workflow in the German market looks like this: a business collects invoices throughout the month, processes them in whatever internal system it uses (ERPs, invoice management tools, spreadsheets), and then sends a structured data export to its Steuerberater at the end of the reporting period. The Steuerberater imports that data into DATEV Rechnungswesen, reviews and completes the bookings, files the monthly VAT pre-registration return (Umsatzsteuervoranmeldung, or UStVA), and handles year-end closing. The business owner rarely logs into DATEV at all.

This delegation model is why DATEV compatibility matters so much. You are not exporting data for yourself. You are exporting data for a professional who will hold you to the format specification and bill for every hour spent cleaning up a bad import. A correctly structured Buchungsstapel takes seconds to import. A malformed one requires manual correction of every row.

DATEV's market position is hard to overstate. Roughly 40,000 tax advisory firms in Germany use DATEV, covering the vast majority of German SMB accounting. If you are building a product for German business customers or serving them as a bookkeeper, DATEV compatibility is not optional. For context on how this compares to English-speaking market accounting platforms, see the accounting automation software guide.

What "DATEV format" actually covers

"Export to DATEV" is shorthand for several related but distinct file formats. Knowing which one applies to your workflow saves significant confusion.

Buchungsstapel CSV

The most widely used export format. A plain-text CSV file with a fixed structure: two header rows that carry file metadata (company number, fiscal year, date range, data category), followed by one data row per accounting entry. Fields are semicolon-separated. The file has a .csv extension but uses Windows-1252 encoding, not UTF-8. This is the format your Steuerberater's DATEV desktop installation expects when you send them a monthly batch.

The header block carries information that DATEV uses to route the file to the correct company and period. The mandatory header fields include: DATEV format identifier (EXTF), version number, data category (21 for Buchungsstapel), company consultant number (Beraternummer), client number (Mandantennummer), fiscal year start (YYYYMMDD), and the booking period covered.

DATEV XML (Buchungsstapel XML)

An alternative encoding of the same booking semantics, using DATEV's proprietary XML schema. Used primarily for API-based data exchange and for imports into DATEV Unternehmen online (the cloud variant of the platform). The field definitions are identical to CSV but expressed as XML elements. If your tax advisor uses DATEV's cloud services or you are integrating via the DATEV developer portal, XML is the target format.

DATEV Unternehmen online

DATEV's cloud platform that allows businesses to upload documents and bookings directly, with the Steuerberater accessing the same data. Belegtransfer is the document upload component, where original PDFs attach to bookings. Buchungsdatenservice handles the booking import. For teams using Unternehmen online, some of the manual file handoff steps disappear, but the underlying data requirements are identical.

Required fields in a DATEV Buchungsstapel

A DATEV booking row has over 100 possible fields, but most are optional or auto-computed. The fields that must be present and correct for a valid import are:

Umsatz (Betrag) -- The booking amount in the transaction currency. Decimal separator is comma, not period. The value 1.234,56 represents EUR 1,234.56. An export pulling amounts from a system that uses periods (like most English-language software) must convert before writing the file.

Soll/Haben-Kennzeichen -- A single character, S for debit (Soll) and H for credit (Haben). Every booking row carries this indicator alongside the amount, so DATEV knows which side of the account the amount belongs to.

Konto -- The debit or credit account number in your chart of accounts. This is a four- to eight-digit number from SKR03 or SKR04. For most expense bookings, this is the expense GL account.

Gegenkonto -- The counterpart account. For a supplier invoice, the Gegenkonto is typically the accounts payable account (1600 in SKR03, 3200 in SKR04) or the creditor sub-ledger account if you maintain individual creditor accounts.

BU-Schluessel -- Tax code field. Blank means tax-neutral. 9 means 19% German VAT applied. 8 means 7% reduced rate. Other values cover reverse charge, intra-EU acquisitions, and exempt transactions.

Belegdatum -- Document date in DDMM format. March 24 = 2403. The year is not in this field; it comes from the file header.

Belegnummer -- The document reference number. This is your invoice number or a sequential reference you assign. It links the booking row to the attached PDF voucher. It must be consistent with the filename or metadata of the attachment if you are using DATEV Belegtransfer.

Buchungstext -- Free-text description. Not required, but practically essential for a readable journal. Include the vendor name and invoice number so the entry is identifiable without opening the source document.

Kostenstelle / Kostentraeger -- Cost center and cost carrier fields. Optional unless the business tracks costs by project or department. A missing cost center on an entry that should have one creates reconciliation work at year-end.

German chart of accounts: SKR03 vs SKR04

Every account number in a DATEV Buchungsstapel maps to a chart of accounts (Kontenrahmen). The two standard frameworks are SKR03 and SKR04, and they are not interchangeable.

SKR03 organizes accounts by the flow of value through the business, following the classical German bookkeeping tradition. The account sequence loosely follows: liquid assets, receivables, inventory, fixed assets, liabilities, equity, operating revenues, operating expenses. Small and medium-sized businesses in retail, trade, and most services typically use SKR03.

SKR04 organizes accounts by balance sheet position, aligning more closely with the structure used in IFRS and international accounting. Revenue and expense accounts mirror the income statement structure. This framework is more common in holding companies, subsidiaries of international groups, and businesses where the chart of accounts needs to match a parent company structure.

The practical impact for invoice export: the GL account number for the same expense category differs between frameworks. Office supplies map to 4930 in SKR03 and 6815 in SKR04. Software subscriptions map to 4980 in SKR03 and 6840 in SKR04. Telecommunications map to 4920 in SKR03 and 6805 in SKR04.

Export a Buchungsstapel with SKR03 account numbers to a client using SKR04, and every single booking lands in the wrong account. The import will not error out, it will just create a systematically wrong ledger that takes time to identify and reverse.

The correct approach: confirm with the Steuerberater which framework the client uses before writing any account mappings. Build the account mapping as a configurable layer, not a hardcoded lookup, because some businesses use customized account ranges that differ from the standard frameworks. Our integrations feature supports per-org accounting configuration so the right account mapping is applied consistently.

Export workflow: from source data to DATEV-compatible file

The path from a raw invoice (PDF from email, manual upload, or portal capture) to a valid Buchungsstapel row involves several transformation steps.

Step 1: Extraction. Pull structured fields from the invoice: vendor name, invoice number, issue date, due date, currency, subtotal, VAT amount by rate, total, and line items. For invoices arriving by email, this happens automatically when the inbox connection is active. For invoices from specific vendor portals like AWS or Stripe, the capture and extraction are handled by the portal integration.

Step 2: Categorization. Map each invoice to a GL account (Konto) based on the vendor category and line item description. A SaaS subscription from any provider maps to software expenses. A cloud infrastructure bill maps to hosting costs. An office supply order maps to consumables. This mapping step is where your SKR selection matters. Each vendor can be assigned a default Konto so the categorization is consistent across periods without manual review.

Step 3: Creditor assignment. For supplier invoices with payment terms, the Gegenkonto is typically a creditor (Kreditoren) account. DATEV supports individual creditor sub-ledger accounts in the 70000-99999 range (SKR03) or 10000-69999 range (SKR04, creditor range), where each vendor gets a persistent account number. Alternatively, you can post everything to a single pooled AP account. Individual creditor accounts give you a cleaner AP aging report and allow your Steuerberater to match payments to invoices automatically.

Step 4: Tax coding. Assign the BU-Schluessel for each booking row. For domestic German invoices, this is straightforward: 19% VAT = code 9, 7% VAT = code 8, zero-rate = code 40 or blank depending on the transaction type. For cross-border EU purchases under reverse charge, code 89 applies for services received from EU suppliers. Getting these codes right matters because DATEV uses them to populate the UStVA fields automatically.

Step 5: File assembly. Write the header block with the correct Beraternummer, Mandantennummer, fiscal year, and booking period. Append one data row per booking. Encode the entire file as Windows-1252. Save with a .csv extension. Some Steuerberater have a naming convention preference for the file itself; if not specified, use EXTF_YYYYMMDD_YYYYMMDD.csv with the period start and end dates.

Digital vouchers and DATEV Belegbuchungsservice

A booking row in DATEV without an attached source document is technically complete for import purposes but problematic for GoBD compliance and practical review. The Steuerberater wants to see the original invoice PDF alongside the booking so they can verify the amounts and categorization without asking you for it.

DATEV's Digitaler Belegbuchungsservice (DBS) links PDF vouchers to booking rows via the Belegnummer field. The workflow:

1. Assign each invoice a Belegnummer when you extract it. This becomes both the field in the CSV row and the identifier in the voucher upload.
2. Upload the PDF to DATEV Belegtransfer or DATEV Unternehmen online. The upload associates the PDF with the Belegnummer.
3. When the Steuerberater imports the Buchungsstapel, each booking row automatically shows a paperclip icon linking to the attached PDF.

For this to work, the Belegnummer must be a stable, unique identifier per document and consistent between your system and what you upload. Using the vendor's invoice number is convenient but risky: two vendors can issue the same invoice number in the same period, and some vendors change their invoice number format unexpectedly. A safer approach is generating a sequential internal reference per fiscal year (for example, 2026-0043) and storing it alongside the extracted invoice data.

The PDF filename does not need to match the Belegnummer exactly in all DATEV versions, but some Steuerberater setups do require it. Naming each PDF after its Belegnummer (2026-0043.pdf) avoids ambiguity.

Start for free and extract your first 10 invoices without a credit card.

GoBD compliance: what German tax authorities actually require

GoBD (the Federal Ministry of Finance's principles for electronic records) is not a piece of legislation but a set of administrative guidelines that define what constitutes an audit-compliant electronic record. The official GoBD guidance published by the Bundesministerium der Finanzen is updated periodically; the current version dates from November 2019.

For invoice records specifically, GoBD requires:

Unalterability from receipt. An invoice PDF received by email must be stored in its original form from the moment it arrives. A scan of a printed email is not the same as the original PDF. Post-receipt editing of amounts, dates, or content invalidates the document for tax purposes. This means your storage solution must lock files after initial write, not allow overwrites.

Completeness and accuracy of the index. Every stored document must be indexed with sufficient metadata to locate it by period, amount, vendor, and document number. A folder of PDFs with names like invoice_scan_003.pdf does not satisfy GoBD's indexing requirement even if the PDFs themselves are unaltered.

Retention of ten years. The retention period for accounting records under German law (HGB section 257) is ten years from the end of the calendar year in which the document originated. A document from December 2025 must be retained through December 2035. Cloud storage with deletion policies that expire files earlier than that creates compliance exposure.

Audit-trail for system changes. If you reclassify or correct a booking, the original entry and the correction must both be retained. GoBD does not allow silently overwriting bookings. DATEV handles this natively through storno (reversal) entries rather than edits.

Accessibility on demand. German tax inspectors (Betriebspruefung) can request access to electronic records in a machine-readable format during a business audit. DATEV's audit export (IDEA-compatible format) satisfies this requirement. Keeping records only in a disconnected PDF archive without structured data fails this standard.

For comparison, the US IRS's approach to electronic records is documented in IRS Publication 583, which covers starting a business and keeping records. The retention periods (three to six years for most records) are shorter than GoBD's ten-year requirement, but the core principle of unalterable, indexed, accessible records is the same.

Common pitfalls that break DATEV exports

These are the failure modes that appear most often when building or first running a DATEV export.

Wrong chart of accounts

Already covered above, but worth repeating because it is the most costly mistake. A systematically wrong SKR selection produces a file that imports cleanly but posts every expense to the wrong account. There is no import error to catch it. The Steuerberater notices during review and must create reversal entries for every affected booking. Confirm the framework before running the first export.

Date format not converted

DATEV's Belegdatum field expects DDMM, not any other date format. Systems that store dates as ISO 8601 (YYYY-MM-DD) or Unix timestamps must convert. A date parsed from 2026-03-24 must be written as 2403. Failing to convert does not always produce an error during import; some DATEV versions accept the field with an unrecognized format and default to January 1, which means your Q1 expenses all post as January entries.

UTF-8 encoding instead of Windows-1252

Any vendor name, booking text, or address that contains a German umlaut (A, O, U with umlauts, or the Eszett character) will be garbled if the file is encoded in UTF-8. The DATEV importer reads CP-1252. A vendor named "Gmbh Bueroservice Muehlstrasse" exports cleanly in CP-1252. The same string in UTF-8 produces "Gmbh B\xc3\xbcroservice" or similar artifacts that appear wrong in the DATEV booking view and cause the Steuerberater to flag the entry.

Missing or duplicate Belegnummer

Belegnummer must be unique within a fiscal year for the digital voucher link to work correctly. If two invoices in the same batch share a Belegnummer, DATEV accepts both bookings but only one voucher attachment, leaving the other booking without a linked document. A common source of duplicates is using the vendor's invoice number without checking for collisions. Assign your own sequential internal reference and use it as the Belegnummer.

Amount decimal separator

German number format uses a comma as the decimal separator and a period as the thousands separator. EUR 1,234.56 in English notation is 1.234,56 in the DATEV file. A system that exports 1234.56 (period as decimal) produces an amount that DATEV reads as 123456 or rejects outright. Run a sanity check on the first few exported amounts before handing off to the Steuerberater.

BU-Schluessel left blank for taxable transactions

A blank BU-Schluessel tells DATEV the booking is tax-neutral. If the invoice includes recoverable input VAT and you want that to flow into the UStVA report, the BU-Schluessel must carry the correct tax code. Leaving it blank on a 19% VAT invoice means the VAT amount posts correctly in absolute terms but does not get counted in the input tax field of the pre-registration return. Your Steuerberater will find this in the first month, but it is better to not create the rework in the first place.

Encoding of the file header

The two header rows in a Buchungsstapel CSV are structured, not free-form. The first row contains field names in DATEV's naming convention, the second carries the values. A common error from templating a CSV in code is adding extra columns, reordering fields, or including a BOM (byte order mark) at the start of the file. DATEV's importer is not tolerant of deviations from the header structure. Use DATEV's published header template verbatim and only modify the data value fields.

Putting it together: the practical setup

The cleanest workflow for businesses sending invoices to a Steuerberater monthly:

1. Connect your invoice sources (email inboxes, vendor portals like Azure and other cloud providers) to a central extraction tool that captures structured data from every incoming invoice.
2. Configure the account mapping once, per SKR framework, with per-vendor overrides where needed.
3. At the end of each reporting period, run the DATEV export. The tool generates the Buchungsstapel CSV with correct field ordering, CP-1252 encoding, DDMM dates, and comma-decimal amounts.
4. Upload the PDF vouchers to DATEV Belegtransfer or share via DATEV Unternehmen online, linked by Belegnummer.
5. Send the CSV to the Steuerberater. Import takes seconds on their end.

For teams already using Xero or QuickBooks alongside DATEV (common in companies with an international parent), the same invoice data can route to multiple destinations. See integrate with Xero and integrate with QuickBooks Online for how those parallel exports work.

For teams comparing specialized DATEV-prep tools against more general AP automation platforms, the accounting automation software guide covers the trade-offs, and the alternativeto comparison hub gives a structured view of what each category of tool handles well.

The DATEV format has a reputation for being difficult. That reputation is partly earned (the encoding, date format, and BU-Schluessel requirements do catch people out), but the underlying structure is logical once you understand the German bookkeeping workflow it was designed to support. A correctly configured export pipeline runs unattended every period, and the Steuerberater gets a clean file with no questions.

The DATEV developer portal at developer.datev.de covers the Buchungsstapel specification and API integration options in full. The field definitions there supersede any unofficial documentation.