DAC7 XML validation: schema rules and common errors
A DAC7 report is an XML file that has to pass two gates: the official OECD/EU schema, and the business rules the tax authority runs on top of it. This guide explains both and lists the errors we see most — then check your own file with the free DAC7 XML validator.
Gate one: the DPI XML schema
Every EU member state uses the same OECD DPI XML Schema, version 1.0, for DAC7. It is three files: DPIXML_v1.0.xsd with the message itself, and two type libraries for country and currency codes and for the document specification. A file has a MessageSpec header (who sends it, to whom, which period) and a DPIBody with one PlatformOperator and its ReportableSellers.
Schema validation is mechanical: an element in the wrong order, a missing currency, a date in the wrong format or a code that is not in the list fails it, and the authority does not read any further. The BZSt answers a schema failure with error code 50007 and rejects the whole delivery.
Gate two: business rules
The schema cannot know that a reporting period must end on 31 December, that a DocRefId must never be reused, or that a correction (OECD2) must name the record it corrects in CorrDocRefId. Those are business rules. The BZSt publishes its list with error codes — see the BZSt format guide for the German specifics.
The errors that fail most files
ReportingPeriod is not a valid xs:date, or is not 31 December
Write the last day of the calendar year as YYYY-MM-DD: 2026-12-31 for the 2026 report. Formats like 31.12.2026 fail the schema; dates like 2026-06-30 pass it but are rejected as a business rule.
This element is not expected. Expected is ( dpi:Name )
A required element is missing, or the elements are in the wrong order. The DPI schema uses fixed sequences: in a seller's identity, for example, ResCountryCode, TIN, IN, VAT, Name and Address come in that order.
The attribute 'currCode' is required but missing
Every amount (ConsQ1–4, FeesQ1–4, TaxQ1–4) needs its currency: <dpi:ConsQ1 currCode="EUR">1200</dpi:ConsQ1>.
'1200.50' is not a valid value of the atomic type 'xs:integer'
Amounts are whole units without decimals or thousands separators. Round to the nearest unit: 1200.50 becomes 1201 or 1200 depending on your rounding policy.
The value 'HOTEL' is not an element of the set {'DPI901', …}
Code lists are closed. Property types are DPI901–DPI910 (DPI910 is other, with OtherPropertyType as free text); nexus codes are RPONEX1–RPONEX5; document types OECD0–OECD3.
No matching global declaration available for the validation root
The file does not start with a DAC7 root element, or the namespace declaration is missing. The root must be <dpi:DPI_OECD xmlns:dpi="urn:oecd:ties:dpi:v1" …> (or <dip:dip> for the BZSt mass-data interface).
DocRefId is used twice
Every PlatformOperator and ReportableSeller record needs its own DocRefId, unique across all your deliveries — not only within the file. Generate a UUID per record.
Placeholder TIN or birth date
Values such as "unknown", "12345678910" or a birth date of 1900-01-01 are not accepted. If a seller has no TIN, leave TIN empty with unknown="true" and report the place of birth instead.
Validate before every submission
Authorities reject a file as a whole for structural problems, and every rejected delivery has to be resent with fresh IDs. Run the file through a validator after each export, not only the first time: a single seller with an emoji in their name, or one amount with decimals, is enough to fail a report with thousands of correct records.
Frequently asked questions
What is the DAC7 XML schema?
It is the OECD's DPI (digital platform information) XML Schema, adopted by the EU for DAC7 (Council Directive (EU) 2021/514). Version 1.0 defines the message header, the reporting platform operator and each reportable seller with their relevant activities, quarterly consideration, fees, taxes and activity counts. Germany's BZSt, like other EU authorities, accepts files built on it.
Is passing the XSD enough?
No. The schema checks structure and data types. Tax authorities add business rules on top — the reporting period must be 31 December, references must follow a set format, corrections must point at accepted records. The BZSt lists its rules with error codes in its Kommunikationshandbuch; a file can pass the XSD and still be rejected.
What is the difference between a file error and a record error?
At the BZSt, a file error rejects the whole delivery (status ERROR) and you resend everything with new MessageRefId and DocRefIds. A record error rejects only that seller (status PARTIALLY_REJECTED); you fix it and send the seller again as a supplementary delivery. Errors on the PlatformOperator record count as file errors.
Which encoding must the file use?
UTF-8. Files exported as UTF-16 or as Windows-1252/Latin-1 break characters such as ä, ß and é, and the BZSt rejects characters outside the basic Unicode range (such as emoji in a seller name).
More on DAC7
DAC7 XML validator
Upload your DAC7 file and get schema and BZSt business-rule errors in plain English.
DAC7 Germany: the BZSt format
DIP envelope or portal upload, ID formats, TINs and the rules the BZSt adds to the schema.
DAC7 deadline: 31 January
When the report is due, when you can first file it, and what to prepare in January.
Validate the TINs and VAT numbers inside your report
The validator checks VAT number formats offline. A free TaxID account checks each seller's VAT number live against VIES and national registries — 100 validations a month, by API or CSV upload, no credit card.
Create a free accountDAC7 report generator
Coming soonUpload a CSV of your sellers and get a schema-valid DAC7 XML for the BZSt (and other EU authorities). Not available yet — join the waitlist and we will email you when it is. Joining is free and commits you to nothing.
TaxID is not a tax adviser. These pages explain the published technical rules; whether and what you must report depends on your platform and is a question for your adviser or the tax authority.