DAC7 Seller Due Diligence: How Platforms Check TINs Before They Report
Under DAC7 a platform cannot confirm that a seller’s tax identification number was really issued to that seller: no EU-wide service does that. What it can do, and what the directive asks of it, is check that each TIN has the structure of the Member State the seller named as its issuer, that this Member State is plausible for the seller, and that the TIN is consistent with the rest of the seller’s data, then keep a record of having checked. Doing it at sign-up, while the seller is still on the page, is far cheaper than doing it in January.
What DAC7 requires
Council Directive (EU) 2021/514 asks platforms to collect, for each reportable seller, the name, the primary address, any TIN with each Member State of issuance (or the place of birth where there is no TIN), the date of birth for individuals and, for entities, the VAT number where available and the business registration number. The TIN can be left out only where the seller’s Member State of residence does not issue one or does not require its collection.
Collection is not enough. Annex V, Section II C(1) requires the platform to “determine whether the information collected … is reliable, using all information and documents available to the Reporting Platform Operator in its records, as well as any electronic interface made available by a Member State or the Union free of charge to ascertain the validity of the TIN and/or VAT identification number.” Due diligence must be completed by 31 December, the report filed by 31 January, and records kept for five to ten years. A seller who still has not provided the required information after two reminders, and at least 60 days after the first request, must have the account closed or payments withheld.
What “TIN matching” can mean under DAC7
“TIN matching” comes from US practice, where the IRS confirms that a name and a TIN belong together. The EU interfaces the directive refers to confirm only that a number follows a Member State’s published structure and check digit, not that it was issued or to whom. In practice that leaves four checks:
The number has the structure used by the issuing Member State. One that fails cannot be right, whoever typed it.
The issuing Member State is plausible. Under Section II D(1), a seller is treated as resident in the Member State of its address and also in the Member State that issued its TIN. A correct number filed against the wrong issuing state gives the seller a second residence, and its data goes to a country that has nothing to do with it.
The TIN is consistent with the name, address and identity documents the platform already holds.
Any challenge from a tax authority is followed up within the procedure the directive sets out.
Where seller data goes wrong
Most errors are ordinary: an identity card number in the tax number field, a VAT number given as the TIN, a new country’s number with an old address, a blank issuing state. A form that only checks the field is filled lets all of them through, and they come back months later as records the receiving authority cannot use or as correction requests for individual sellers.
They also travel. The January report joins, per seller, identity from onboarding, the payout account from payments, quarterly amounts from the ledger and, for rentals, listing details from the catalogue. The residence field decides which countries receive the record, and it depends on the TIN and its issuing state. An error there does not make the file invalid. It sends a correct-looking record to the wrong country.
Validating at sign-up removes the structurally impossible numbers before they reach any of those systems, returns a reason the seller can act on, and produces the record of the check that DAC7 asks for anyway.
What the DAC recast would change
On 24 June 2026 the Commission proposed a recast of the Directive on Administrative Cooperation, COM(2026) 308. For platforms it would remove the activity criterion for sellers of goods and raise the threshold from EUR 2,000 to EUR 3,000 a year, exempt small platform operators and transactions between related entities, and clarify the rules for intermediary sellers. Due diligence and the 31 January deadline stay unchanged. The dates are still in square brackets, 1 January 2028 for the new threshold and 1 January 2030 for the rest, and the proposal needs unanimity in the Council.
When DAC7 is not the only report
DAC7 on its own involves only TINs issued by Member States. Many platforms do not stop there.
Since 1 January 2026, the amended Common Reporting Standard in the EU treats any entity holding electronic money for customers as a depository institution. A platform that keeps seller balances in its own e-money wallet, or the e-money issuer running that wallet, has CRS obligations on those accounts. Accounts whose 90-day average balance stays below USD 10,000 all year are excluded. Above that line, the platform must collect the TIN of the seller’s country of residence, wherever that is.
The same applies to platforms with sellers outside the Union. The OECD Model Reporting Rules for Digital Platforms, on which DAC7 is modelled, apply in the United Kingdom and Canada since 1 January 2024, and in New Zealand, Norway and other jurisdictions, each with its own number formats.
For these businesses the seller is onboarded once and the TIN feeds more than one report. Checking EU numbers one way and everything else another means two integrations, two sets of error handling and two records to keep. One validation layer that covers EU and non-EU numbers alike keeps a single check at the point of entry, and a single record of it.
Where this leaves a platform
The DAC7 work that pays off is done at sign-up: a structural check on every TIN against the issuing country, a plausible issuing state, and a record of both. For a platform that reports only under DAC7, that covers Member State numbers. For one that also holds seller balances or has sellers outside the Union, the same check has to cover every country its sellers come from. What happens to those numbers further down the line, from onboarding to the January file, is covered in TIN validation at scale, and the compliance case for validating at all in why TIN validation matters for CRS compliance.
Open Automation’s OpenTIN API validates EU and non-EU tax identification numbers in one call, for 107 jurisdictions that issue them, and is available on AWS Marketplace and Azure Marketplace. Learn more at open-automation.io/opentin-api.
Provisions cited are from Council Directive (EU) 2021/514 as published in the Official Journal, L 104, 25 March 2021. The DAC recast is a proposal and may change before adoption.