"It's just an XML" - famous last words 💀

If you are a CTO or Product Manager at a digital marketplace, you probably heard this sentence from your legal team last year: "We just need to generate an XML file for the tax office. It’s a standard EU directive."

It sounds innocent. A simple data export. A weekend hackathon project.

I am here to tell you that this is a trap.

The implementation of DAC7 (Directive on Administrative Cooperation) is not a "feature." It is your platform nightmare wrapped in a bureaucratic enigma. While the specific pain points and error codes described below come from the Czech Republic experience, the implementation hell is universal. Whether you are integrating in Germany, France, or The Netherlands, you are likely walking into a similar landscape of technical debt, user friction, and operational pain - the 5 Circles of Hell.

Circle 1: Data Collection (The UX Suicide)

The first circle isn't even technical - it's product suicide. You need to ask your sellers for data they don't want to give you, for a reason they don't understand.

The directive requires you to collect Tax Identification Numbers (TINs), dates of birth, and permanent addresses. For Czech individuals, this means the Rodné číslo (Birth Number).

The Problem: Czech users are hyper-sensitive about their Birth Numbers. When you suddenly throw up a "blocker" modal asking for this sensitive data to comply with a tax law, conversion rates drop.
The Technical Pain: You have to implement "Chase Logic." You can't just ask once. You need a state machine that tracks how many times you've asked, sends reminders after X days, and eventually triggers a "Kill Switch" to freeze their payouts after 60 days of non-compliance. This isn't a simple form; it's a complex workflow engine deeply integrated into your user account service.

Circle 2: Data Validation (The Regex Trap)

So you collected the data. Now you have to validate it. You might think, "I'll just use the EU VIES API."

Wrong. VIES only validates VAT numbers for businesses. It tells you nothing about the thousands of private individuals (non-VAT payers) selling on your platform.

The TIN Mess: There is no unified API to check if a German, French, or Czech personal TIN exists. You are left with syntactic validation. You have to build or find a library of Regex patterns for every single EU country.
The Address Parser: The Czech Financial Administration requires addresses split into structured fields (City, Street, Building Number). But your database probably has "Ulice 5, Praha" as a single string. You will spend a good amount of time writing parsers to separate the číslo popisné from the číslo orientační, knowing that if you get it wrong, the report will be rejected. And if you happen to have sellers from other EU countries on your platform, well, I pity you.

Circle 3: The XML Generation (Schema Hell)

You’ve got the data. Now you generate the DAC7 XML. The OECD schema looks standard until you meet the Czech implementation reality.

The Encoding War: Modern systems use UTF-8. The Czech financial infrastructure has a long history with Windows-1250. If a seller copy-pasted a "non-breaking space" or an invisible control character into their profile, your XML might pass your internal validator but fail instantly on the Financial Administration's gateway with a generic Error 40001.
The Currency Curveball: You must report in the currency of the payout. If you operate in CZK, EUR, and PLN, you cannot just aggregate them. You need sub-ledgers in your XML generation logic.
The UUID Collision: The MessageRefId must be globally unique. If you accidentally reuse an ID from your staging environment in production, the Tax Office's system (ADIS) will reject it as a duplicate. You need a robust ID generation strategy that persists across your entire infrastructure.

Circle 4: Submission Frictions (The Missing API)

This is where the "tech" illusion breaks. You expect a REST API with a Bearer token, like Stripe or AWS.

What you get: A SOAP interface from the 2000s or a manual upload portal.

The Transport Layer: To automate submission, you must integrate with ISDS (Data Boxes) or the EPO interface using SOAP/WSDL. There is no POST /v1/submit-report.
The Signing Ceremony: You can't just send the file. You often need to sign the payload with a Qualified Electronic Signature (ZAREP) or rely on the "fiction of signature" via Data Box. Managing these certificates on a server is a security headache.
The 10MB Limit: If your marketplace is successful, your XML will be huge. The EPO gateway has a file size limit (historically around 10MB for direct uploads). You have to implement logic to split your report into multiple batches (DAC7_Part1.xml, DAC7_Part2.xml), ensuring you don't break a single seller's data across two files.

Circle 5: The Feedback Loop (Chain of Corrections)

You sent the report. You think you're done. You are not.

The Tax Office processes data asynchronously. Days later, you might receive a "Protocol of Errors."

The Correction Logic: DAC7 doesn't let you just "re-upload the corrected file." It uses a differential correction mechanism. To fix one seller's typo, you must send a new XML containing only that seller, referencing the specific DocRefId of the original record you sent months ago.
State Management: This means you must store the UUID of every single record you have ever sent to the government. If you didn't architect your database to keep this "state" of submission history, you cannot automate corrections. You will be manually editing XMLs in Notepad++ while your legal team breathes down your neck reminding you about the Jan 31st submission deadline.

The Conclusion

Building a DAC7 reporting engine isn't "just" about generating a file. It's about building a Compliance Operating System that handles:

User harassment (notifications).
Data hygiene (validation).
Legacy interoperability (SOAP/XML).
Long-term state preservation (corrections).

The question isn't "Can we build this?" Your team is smart; of course they can.
The question is "Should we?" Every hour your engineers spend debugging a SOAP envelope or researching Czech XML schemas is an hour they aren't building value for your customers.

Don't reinvent the bureaucratic wheel. Use a dedicated solution.

DAC7: The 5 Circles of Hell (and why you don't want to build this)

Table of Contents