OECD DPI XML Schema and User Guide
Approved 17 March 2022. Sets the elements, the code lists and the requirement levels this checker reads.
DAC7 Seller Data Checker
Free DAC7 Seller Data Checker
Check a seller export against the OECD DPI XML Schema in your browser, then take away a chase list naming every seller, field and fix. Nothing is uploaded.
Runs in your browserChase list CSVDPI XML draft
0
Bytes of seller data uploaded
252
Country codes checked against the schema list
186
Currency codes the schema accepts
4
Quarterly blocks checked on every activity
What the checks are based on
Every finding cites a page or a schema rule
Findings come from the DPI XML Schema v1.0 and from the OECD User Guide that documents it, and each one carries the page or the element it came from so you can check the reasoning against the source rather than take it on trust. Gruv holds no tax licence and files nothing on your behalf.
Council Directive (EU) 2021/514
DAC7. Where the guide marks an element EU Specific, the requirement comes from here, and the checker labels the finding the same way.
Schema and code lists transcribed from OECD Model Rules for Reporting by Digital Platform Operators XML Schema: User Guide for Tax Administrations, checked 1 September 2026. Member States publish their own variants of the schema, so validate any draft against the XSD of the route you file through.
Loading the checker…
Method
Two sources, and a severity that means something
Every check here comes from one of two places. The first is the DPI XML Schema v1.0 itself, which enumerates 252 country codes, 186 currency codes and 27 Member State codes, and types a monetary amount as a whole number. A value outside those lists is rejected by any validating parser, so the checker calls it blocking. The second is the OECD User Guide, which sets requirement levels and page by page says which elements must be present. A missing business registration number loads fine and still breaches DAC7, so the checker calls that required rather than blocking, and cites the page.
Take a file of 4,000 rows where 900 individual sellers have no TIN. The blocking count is zero for those rows if each one is flagged unknown, because the guide accepts NOTIN with the unknown attribute set. What the checker returns instead is 900 required findings against place of birth, because DAC7 asks for the city and country of birth exactly where no TIN is available. That distinction decides your next four weeks: chasing 900 tax numbers is a different project from filling in 900 birth places you may already hold in the sign-up record.
What it will not do matters as much. It does not check a TIN against a Member State format, because those formats are set by each filing Member State rather than by the schema, and a confident false failure on correct data would be worse than no check. It does not decide whether a seller is in scope, which is a due diligence question about the seller. The XML it writes is a draft: several Member States publish their own variant of the schema, so validate it against the XSD of the route you file through before you submit anything.
Checked 1 September 2026. Tool pages carry figures that change, so confirm anything you rely on against the authority that publishes it.
Process
How it works
- 01
Load the export
Drop or paste a CSV. It is read in the browser and never sent anywhere.
- 02
Read the readiness view
Findings grouped by cause, split into blocking, required and worth checking.
- 03
Take the chase list
One CSV line per gap, naming the seller reference, the field and what to ask for.
- 04
Check the draft against your XSD
Add the filer details, then validate the draft where you file.
Audience
Who uses this
Marketplace finance and tax teams
Size the gap in a seller book before the January filing date arrives.
Compliance operations
Turn a schema failure into a list of sellers to contact, with the reason attached.
Platform engineering
See which columns your export is missing before writing the XML mapping.
Vendor selection
Understand your own data quality before a filing vendor quotes on it.
Frequently Asked Questions
Is my seller file uploaded anywhere?+
No. The file is read with the browser FileReader, checked in memory, and the downloads are built in the page. There is no upload endpoint in this tool.
Does this file my DAC7 return?+
No. Gruv does not file returns. The tool produces a chase list, a readiness view and a draft XML you check against the schema published by the administration or filing partner you submit through.
Why does it not validate TIN formats?+
TIN formats are set by each filing Member State rather than by the DPI schema. Encoding them would produce confident false failures on correct data, which is worse than saying plainly that the check is out of scope.
What is the difference between blocking and required?+
Blocking means a validating parser rejects the file, so it does not load at all. Required means the schema accepts it while the OECD Model Rules or DAC7 ask for the data, so the filing loads and is incomplete.
How should property rentals be laid out?+
One row per property listing. Consideration and the number of activities are reported separately for each listing, so a seller with three listings is three rows sharing one seller reference.
Which schema version does the draft follow?+
The OECD DPI XML Schema v1.0, published March 2022, with the namespaces urn:oecd:ties:dpi:v1, urn:oecd:ties:dpistf:v1 and urn:oecd:ties:isodpitypes:v1. Some Member States publish a variant of it, which is why the draft is a draft.
The gaps are in the payout record too
Most DAC7 gaps start where seller onboarding stopped asking. Gruv keeps tax and payout details on one seller record, with form readiness gated and exportable for filing partners. Talk to the team about what your data looks like.
Many teams start with a narrow launch in weeks.