Invoicing customers whose tax advisor works with DATEV
Your customer — or their tax advisor — works with DATEV. You send them a checked e-invoice instead of a PDF someone there has to retype.
Many business customers hand their documents to a tax firm that works with DATEV, or book in DATEV themselves. By DATEV's own description, e-invoices can be processed with DATEV Unternehmen online; they arrive there via DATEV Upload Mail, via Upload online or optionally via an e-invoice mailbox. Your side of the route is the invoice itself: the API turns your invoice data into an XRechnung or a ZUGFeRD PDF to EN 16931 and checks it before it leaves. It is sent as before, usually by email to your customer. The recipient's DATEV setup stays as it is — you do not change anything on their side.
What comes in
Invoice data from your invoicing software, your ERP or your template
Line items with quantity, unit, unit price and tax rate
Bank details and payment term — mandatory for XRechnung
The address your customer already receives invoices at today
What this solves
Data instead of retyping on the recipient's side
A PDF without structure has to be keyed in by someone at the customer or the tax firm. An e-invoice to EN 16931 carries number, parties, line items and tax amounts as fields — it is read in rather than retyped.
One record, two formats
The same invoice data yields an XRechnung or a ZUGFeRD PDF. Your customer tells you which one they want; you do not maintain a second invoicing route for it.
Checked before the tax firm notices
The validate endpoint checks XRechnung against the XRechnung rules (KoSIT) and ZUGFeRD against its profile Schematron and the EN 16931 rules — and names the rule and the field. A missing tax rate, or the contact XRechnung requires, shows up on your side — not after the month has already been booked at the recipient.
People still see a PDF
ZUGFeRD is a PDF/A-3 with embedded XML. Whoever checks or approves the invoice reads the page; the accounting software reads the attachment.
One real example
An excerpt from the recipe “Generate and send a ZUGFeRD PDF” — including bank details and payment term, which travel in the embedded XML.
{ "invoice": { "invoiceNumber": "RE-2025-002", "issueDate": "2025-01-15", "buyer": { "name": "Beispiel AG" }, "items": [ { "position": 1, "description": "Beratungsleistung", "quantity": 10, "unit": "HUR", "unitPrice": 150, "taxRate": 19, "netAmount": 1500, "taxAmount": 285, "grossAmount": 1785 } ], "total": 1785, "seller": { "bankAccount": { "iban": "DE89370400440532013000", "bic": "COBADEFFXXX" } }, "paymentTerms": { "dueDays": 30, "description": "Zahlbar innerhalb von 30 Tagen" } }}POST /api/v1/invoice/DE/zugferd/generate
Response: a Base64-encoded PDF/A-3 with embedded EN 16931 XML. The line item computes 10 × 150.00 € = 1,500.00 € net, 19 % adds 285.00 € tax, total 1,785.00 € — the same values that appear in the input above, as do the IBAN and the payment term.
The full recipeThe endpoints involved
- Invoice CreatorLive
POST /api/v1/invoice/{countryCode}/{format}/generate
- ValidatorLive
POST /api/v1/invoice/{countryCode}/validate
Compared to the alternative
DATEV is the software on your customer's and their tax firm's side. We do not replace it and do not compete with it: we supply the e-invoice that gets processed there. What we do compare ourselves against is other e-invoicing APIs — the comparison shows the differences.
Read the comparisonHow it runs
- 1
Ask your customer whether they want XRechnung or ZUGFeRD and at which address — often it is the same one today's PDF goes to.
- 2
POST /api/v1/invoice/DE/validate, then .../zugferd/generate or .../xrechnung/generate with your invoice data.
- 3
Send the file by email to your customer as before; the route into their DATEV setup is theirs to choose.
What it costs at this volume
Around 300 invoices per month fit the Starter plan at 23 € per month.
All prices net, plus VAT · 20 % off when billed annually · Free tier without a credit card
All plansLimits
- Direct delivery into the DATEV e-invoice mailbox via the TRAFFIQX network is not available yet — planned for Q1/2027. Until then the API creates the file and you send it through your existing channel.
- The API produces no DATEV export files and no booking batch — neither for your own bookkeeping nor for your customer's.
- How the invoice is processed further in DATEV on the recipient's side is up to them and their tax firm, not the API.
- Audit-proof archiving is not part of the API (Archive API planned 2027).
Build it yourself or have it built
Both routes end at the same e-invoice. The difference is who writes the integration.
Build it yourself
You call the API yourself. 300 invoices per month fit the Starter plan at 23 € per month billed monthly, or 18 € per month billed annually.
All prices net, plus VAT · 20 % off when billed annually · Free tier without a credit card
To the quickstartHave it built
We connect your existing system: 6,000–15,000 € plus VAT at a fixed price, 4–6 weeks to go-live.
Fits when your invoices come out of a system that has grown over years and several customers ask for e-invoices for their tax firm — the integration is then built once alongside it rather than by hand per customer.
All amounts net, plus VAT.
To the integration serviceFrequently asked questions
Does my customer or their tax firm have to change anything?
What changes on your side is the format, not the delivery route: the invoice goes to the address your customer gives you, as before. How it gets from there into their DATEV setup — for example via DATEV Upload Mail — is for them and their tax firm to decide.
Can you deliver directly into the DATEV e-invoice mailbox?
Not yet. Delivery via the TRAFFIQX network is planned for Q1/2027; status and flow are on the docs page on DATEV delivery. Until then the API creates and checks the invoice, and sending it stays your step.
Do you generate DATEV booking data?
No. The API creates e-invoices to EN 16931 — XRechnung and ZUGFeRD — not DATEV export formats and no booking batch. Booking stays with the recipient and their tax firm.