DSFinVBV: Die neue Schnittstelle für deine Buchführungsdaten

Germany's Federal Ministry of Finance (BMF) is working on a regulation that will define the format in which you have to hand over your bookkeeping data to a tax audit in future: the Buchführungsdatenschnittstellenverordnung, DSFinVBV for short. It sounds like a purely technical matter, but it carries a sharp legal consequence. Under § 158 (2) no. 2 AO, a faulty data export can strip your entire bookkeeping of its evidential value. Here's the current status, the criticism from the professional associations, and an honest assessment of what you should do today – and what you shouldn't.

What exactly is the DSFinVBV?

The bookkeeping data interface regulation is meant to establish a uniform technical standard for how companies transmit their bookkeeping data to the tax authorities during a tax audit (Außenprüfung). The legal basis is § 147b of the German Fiscal Code (Abgabenordnung, AO). That enabling provision isn't new: it was inserted into the AO by the DAC-7 Implementation Act of December 20, 2022, and has been waiting to be filled with substance ever since.

The problem the regulation aims to solve is real. Tax auditors today receive bookkeeping data in wildly different formats: sometimes as a GDPdU export, sometimes in a software vendor's proprietary format, sometimes as a CSV wasteland. The conversion effort on the authorities' side is high, and media breaks are the rule. A standardized export really would speed up audits – for both sides.

That's exactly why the professional associations welcome the project in principle. Their criticism isn't aimed at a uniform standard as such, but at how this particular draft is designed.

The timeline: a long run-up

The road to the DSFinVBV has been dragging on for years:

• December 1, 2023: The BMF publishes the first discussion draft.
• 2024/2025: A second draft follows; consultation runs mainly with IT specialists and software vendors.
• Spring 2026: The BMF sends a revised version to the associations.
• June 11, 2026: The Federal Chamber of Tax Advisers (BStBK) files its statement.
• June 12, 2026: The German Association of Tax Advisers (DStV) follows with statement S 05/26. The consultation period ends.

The associations are particularly critical of who was allowed in the working groups. The BMF initially spoke mainly with software manufacturers. The companies and firms that will have to apply the standard later were, in the DStV's view, not sufficiently involved. Since the legal requirements and the technical data standard are tightly interlocked here, the DStV considers joint participation of all groups essential.

Who would be affected?

This is one of the biggest points of contention. On a broad reading of the draft, in addition to companies with a classic bookkeeping obligation, freelancers, farmers and foresters, as well as associations and corporations with a commercial business operation could be covered. And it wouldn't stop at financial accounting: upstream systems would be affected too, meaning electronic cash registers, ERP/merchandise management systems, and document management systems.

The DStV considers this too far-reaching. Anyone determining profit via the cash-basis P&L under § 4 (3) EStG doesn't keep books in the proper sense. The association therefore demands that these cases be explicitly excluded, or at least covered by a significantly reduced data set.

What this means for you: whether you'd even be affected is still open. If you file an EÜR, there's a good chance you'd stay out of scope or would only have to deliver a minimal set. If you prepare a balance sheet and work with a cash register, ERP, or DMS, keep an eye on this topic.

The real explosive: § 158 (2) no. 2 AO

At the heart of the criticism is not the regulation itself, but a rule that is already applicable law. § 158 (2) no. 2 AO provides: if bookkeeping data is not made available in accordance with the specifications of the uniform digital interface, the evidential value of the bookkeeping falls away to that extent. And once the evidential value is gone, the tax office may estimate the tax bases under § 162 (2) AO.

Put simply: a technical error in the data export could trigger an estimate even though your bookkeeping is complete and correct in substance. Not because you posted anything wrong, but because an interface failed to populate a field cleanly.

The DStV considers this consequence disproportionate, and the reasoning is convincing: the factual correctness of bookkeeping follows from the principles of proper bookkeeping (GoB) and the statutory record-keeping rules. It does not depend on whether a complex data export runs through without technical faults. The association points to Federal Fiscal Court (BFH) case law under which high requirements apply before formally proper bookkeeping may be rejected. What's needed are indications of material incorrectness with near-certainty (BFH judgment of August 9, 1991, III R 129/85, BStBl. II 1992, p. 55). Technical interface defects don't meet that standard.

One caveat, though: § 158 (2) no. 2 AO is the newer and more specific provision. Whether and how the older BFH case law carries over to it has not been conclusively settled.

The BStBK goes further and raises constitutional concerns. Its argument: the far-reaching legal consequence is anchored in the Fiscal Code, but its decisive preconditions would effectively be outsourced to a statutory instrument. That raises doubts regarding clarity of norms and the hierarchy of norms. Moreover, non-compliance might not merely open up a power to estimate, but in practice amount to an obligation to estimate. Both associations jointly demand that § 158 (2) no. 2 AO be deleted. Only the legislator can do that, however, since the provision sits in the statute, not in the regulation.

Does the regulation create new record-keeping obligations?

The second major criticism concerns the scope of the data. The draft lists numerous data fields that are supposed to belong to the so-called minimum scope. Many of them are not kept as standard in practice today.

The DStV sees a contradiction in the text here: on the one hand, books and records are supposed to "comprise" the listed data and provide it as a "minimum scope". On the other hand, the export obligation is only supposed to reach as far as a statutory record-keeping duty exists. That ambiguity could create the impression that companies must maintain all the listed fields going forward.

Specifically under criticism, among others:

• Document numbers (external and internal): small companies without open-item accounting don't routinely capture external document numbers in the posting record.
• Posting texts: a posting text doesn't always have to describe the transaction on its own. Traceability often already follows from account, contra account, document, and amount.
• Foreign currency details: a mandatory ISO code seems formalistic when the currency is unambiguously stored anyway.
• Cost allocations (cost centres, cost objects, projects): this data primarily serves internal management and isn't necessarily part of tax-relevant bookkeeping.
• Master data such as the business identification number, foreign tax number, or country code: many companies don't hold these systematically.

The common pattern: additional mandatory fields create capture and maintenance effort without a clearly recognizable benefit for the audit in every case. Small and medium-sized businesses would bear the brunt. The associations' principle is clear: the regulation may only govern the export of data that already exists and is legally required. New substantive record-keeping obligations through the back door wouldn't be covered by the enabling provision in § 147b AO.

When could the DSFinVBV apply?

Under the draft, the regulation would come into force on December 31 of the third year following its promulgation. With promulgation in 2026, that would be December 31, 2029. At first glance, a generous lead time.

The associations still see a problem: implementation presupposes that the technical data standard – including description, structure, and taxonomy – is available in final form. Software vendors can only implement reliably after that; companies and firms can only plan with certainty after that. If the clock starts running with promulgation of the regulation while the technical standard is still missing, the real implementation time shrinks considerably. The DStV therefore demands that the start of the period be tied to publication of the final standard, with a test phase using real data beforehand.

The BStBK points to a practical knock-on problem: if the regulation takes effect on, say, December 31, 2029, an audit covering 2028 to 2030 could trigger the new requirements for 2030. To deliver compliant data for 2030, companies might have to retroactively reformat the already closed years 2028 and 2029 as well. Both associations therefore demand a clear transitional rule plus a hardship rule for legacy systems that no longer receive vendor support.

What you should do now – and what you shouldn't

To be clear: the DSFinVBV is still a draft. It is not in force, and its content can change as the process continues. There is no urgent need to act. Anyone trying to sell you new software right now on the grounds of a "DSFinVBV obligation" is arguing dishonestly.

Three things do make sense nonetheless:

1. Factor it into software decisions. If you're facing a system change anyway, ask the vendor where they stand on the § 147b AO standard. It costs nothing and saves migration effort later.
2. Maintain your process documentation. If you're revising it anyway, document data flows, upstream systems, and interfaces properly. You already need this under the GoBD, and it's the best preparation for any future standard.
3. Keep master data clean. Business identification number, country codes, complete vendor and customer master data: if you've kept these tidy anyway, you'll have less rework later, regardless of how the regulation ends up.

Bookkeeping that holds up in an audit

However the DSFinVBV turns out: clean, structured bookkeeping with traceable documents and well-maintained master data is the best protection against any kind of audit stress. That's exactly what we do for you at Buchführungsheld, with real bookkeepers and at a fixed price. You upload your receipts; we take care of correct posting, the system landscape, and the documentation. If you want to know how audit-proof your current bookkeeping is, book a free initial consultation.

Frequently asked questions

Is the DSFinVBV already in force?

No. It is a draft. The associations were able to comment until June 12, 2026. Whether and in what form the bookkeeping data interface regulation comes into force is open.

Who would the DSFinVBV affect?

On a broad reading, a wide circle of taxpayers with bookkeeping, possibly including freelancers, farmers and foresters, as well as upstream systems such as cash registers and ERP. That very scope is disputed. The DStV demands that cash-basis P&L cases under § 4 (3) EStG be excluded or covered only by a reduced data set.

What is the main criticism from the professional associations?

Two points. First, the concern that the regulation creates new record-keeping obligations through the back door by declaring numerous data fields to be mandatory. Second, the legal consequence under § 158 (2) no. 2 AO, whereby a technical export error can undermine the evidential value of the bookkeeping and trigger an estimate under § 162 (2) AO.

Do I have to change my software now?

No. As long as the regulation is not in force, there is no immediate need to act. It does make sense, however, to factor the topic into upcoming software decisions and into maintaining your process documentation.

What is the earliest the regulation could apply?

The draft provides for entry into force on December 31 of the third year following promulgation. With promulgation in 2026, that would be December 31, 2029. The associations demand that the start of the period be tied to publication of the final technical standard instead.