DATEV Export for SaaS Billing Without the Excel Chaos

Creating an invoice and booking it correctly are two separate jobs. The DATEV export in many SaaS companies breaks down at exactly this handoff: billing, the payment provider, and accounting see the same transaction, but in different states, periods, and data models. The result is clearing accounts with open differences, missing document references, and a month-end close that depends on CSV exports and Excel formulas.

For recurring, usage-based, and hybrid business models, the DATEV export has to do more than output a customer account, an amount, and a GL account. It has to turn correct billing into a traceable journal entry, with tax logic, revenue account, payment status, correction document, and an unambiguous document reference. Only then does billing infrastructure become a finance process you can rely on.

What a DATEV export from billing has to cover

A DATEV export hands a reconciled subledger over to financial accounting. For that handoff to work, product logic and finance logic have to be connected before the export runs.

Take a B2B SaaS company with monthly platform fees, additional seats, and usage-based API calls. An invoice might contain a fixed base price, prorated seat upgrades, usage from the previous billing period, and a promotion. A German customer is charged German VAT. For a verified French business customer, reverse charge may apply. For B2C sales in other EU member states, the EU VAT One-Stop Shop (OSS) can come into play.

So the accounting export needs more than the gross invoice amount. It needs the correct tax code and account mapping for each component of the service, the customer account details, invoice number, invoice date, service period, and a document reference. If payments are posted separately, you also need bank or payment clearing accounts, fees, returned direct debits, refunds, and the matching of payments to open items.

Whether a tool can produce a DATEV file tells you little. The question to ask is whether invoice, payment, and correction can be traced in DATEV, correct in substance and in the right period, without anyone interpreting them by hand.

The most common mistake: mixing invoice data with payment data

Billing systems usually work with events. An invoice is finalized, a payment is collected, a direct debit fails, a retry starts, a credit note is created. Finance needs journal entries from these events, and each entry has to refer to a clearly defined business transaction.

Issuing an invoice usually creates a receivable from the customer and revenue including VAT. When the payment comes in, that receivable is cleared against a clearing account or bank account. A payment provider's fee is a separate expense and doesn't reduce revenue. A failed SEPA direct debit needs its own handling as well: depending on the return reason, it can trigger a reversal, a new receivable, or a fee posting.

If an export only includes paid invoices, open receivables are missing and the period cut-off becomes unreliable. If it nets invoices and payments into one line, nobody can audit payment channels, fees, and reversals anymore. This separation matters most with Stripe, GoCardless, and SEPA Direct Debit, because settlement, fees, and payment status can happen at different times.

A reliable architecture therefore keeps invoice and payment as linked but separate ledger events. The document number, customer account, and matching reference connect them, so nobody has to match them by hand at month-end close.

Account mapping starts in the product catalog

Many teams treat general ledger accounts as part of the accounting setup. For SaaS, that comes too late. When a new plan, add-on, or promotion is introduced, the product catalog already determines which type of revenue will later show up in the general ledger.

Not every SKU needs its own revenue account. A small, manageable account structure is often easier to maintain. It does have to be modeled on purpose, though, because platform fees, usage-based services, professional services, discounts, and refunded amounts can have different business requirements. What matters is that the mapping is versioned and that a price change doesn't retroactively change the accounts on old invoices.

Price changes without a deploy only help if their financial effect stays under control. For every finalized document, a billing system should lock in the pricing, tax, and account mapping logic that applied at the time. Otherwise a later plan change can leave you with export data that no longer matches invoices you've already sent.

Finance and engineering should share one control model that contains at least this data:

• Document number, document date, service period, and an immutable invoice status
• Customer ID, tax country, VAT ID (USt-IdNr.) validation status, and tax treatment
• GL account, tax code, and net, tax, and gross amounts per posting rule
• Payment reference, clearing account, fees, refunds, and matching status
• Source events for variable usage, so billed quantities stay reproducible

These fields keep the export simple, and they stop complexity from surfacing for the first time during reconciliation.

Tax logic has to be decided before DATEV

DATEV can process postings, but it can't fix an unclear tax decision. The export should therefore carry over the tax assessment made during billing. Reconstructing it afterward from country and tax rate is guesswork.

A sale at the German VAT rate, a reverse charge case, and an OSS-relevant B2C sale can have the same product price and still require different invoice details, tax codes, and reporting channels. VIES checks belong to the transaction too: the documented check status and the time of the check are part of its audit trail.

Credit notes need particular care. For tax and accounting purposes, a credit note has to reference the original transaction. Negative revenue with no link to the original document makes both the audit and the settling of the receivable harder. The same goes for goodwill credit notes after a failed delivery and for retroactive usage adjustments.

For invoices under EN 16931, XRechnung, or ZUGFeRD, the underlying document data has to stay consistent as well. The e-invoice and the journal entry are separate records, but the invoice document and the export must not differ in amounts, tax breakdown, or service period.

Period close: keep VAT and revenue recognition apart

A recurring mistake in SaaS finance is to treat the invoice, the VAT, and the revenue as the same thing. All three can fall into the same period, but they don't have to.

VAT follows the applicable tax rules and the transaction that was billed. Revenue recognition under IFRS 15 or ASC 606 follows the satisfaction of performance obligations. If an annual contract is billed in advance, the receivable can arise when the invoice is issued, while the revenue is deferred over the contract term. With usage, revenue recognition may sit closer to actual consumption, depending on the contract terms and the accounting policy.

A DATEV export from billing should therefore define clearly which data stream does which job. The accounts receivable and invoice stream covers receivables, VAT, and billed revenue. A separate revenue schedule or deferral stream can trigger reclassifications between contract liabilities, deferred revenue, and recognized revenue. If you mix both into one export logic, you get differences that are hard to explain.

Cut-off rules have to be explicit too. An invoice dated on the last calendar day whose payment arrives the following month belongs in two different posting periods. A late usage event must not change a period that has already been closed without anyone noticing. If the company needs to bill additional amounts, it should issue new, clearly referenced documents and leave historical invoices unchanged.

How to make the export auditable as well as importable

A DATEV file can be technically valid and still be useless in day-to-day operations. Auditability comes from the chain that runs from the source event to the journal entry. Every posting has to trace back to a document, every document to its line items, and every variable line item to usage events you can follow.

For GoBD-compliant processes, it is especially important that finalized invoices and the records behind their postings are never silently overwritten. Corrections need cancellation, credit note, or corrective invoice logic. The export run itself should also be traceable: which period was exported, which postings it contained, which version of the account mapping rules applied, and whether a repeat export produces identical data.

Kontier connects billing, tax logic, payment operations, and ledger data that accounting can use in a single workflow. A finalized document produces controlled financial events right away, including the DATEV export, payment matching, and corrections, so nobody has to interpret rows at the end of the month.

The practical test is simple. Pick a posting at random. If finance can show the invoice, tax decision, service period, payment status, and source events for it within a few minutes, the process holds up. If that takes several exports, a Slack thread, and an Excel file, the DATEV export isn't yet infrastructure you can close the books on.