Common DAC8 Report Rejection Reasons and How to Fix Them

Category: Troubleshooting Last Updated: 2026-02-12

---

Overview

When a DAC8 XML report is submitted to a tax authority, it typically goes through a series of automated validation checks before it is accepted. If any of these checks fail, the report may be partially or fully rejected. Understanding the most common rejection reasons and how to resolve them can significantly reduce delays in your reporting workflow. This guide covers the primary categories of rejection errors, practical fixes for each, and steps you should take before resubmitting.

> Disclaimer: This article provides general technical guidance. Validation rules, rejection handling procedures, and resubmission processes may vary by EU Member State and by schema version. Always consult the official documentation published by the relevant tax authority and, where appropriate, seek professional advice.

---

XSD Schema Validation Failures

XML Schema Definition (XSD) validation is typically the first automated check performed on a submitted file. If the XML does not conform to the expected schema, the report is expected to be rejected outright.

Common causes include:

• Malformed XML: Unclosed tags, improperly nested elements, or missing the XML declaration ().
• Wrong namespace: The XML namespace URI may not match the version of the schema the tax authority expects. Even a small typo in the namespace string may cause a complete validation failure.
• Encoding issues: Files that declare UTF-8 encoding but are actually saved in a different encoding (such as Windows-1252) may produce parsing errors, especially when user names or addresses contain accented or non-Latin characters.

How to fix:

• Validate your XML against the official XSD locally before submission, using a tool such as xmllint or a dedicated XML editor.
• Confirm that the namespace declaration matches the schema version required for the current reporting period.
• Ensure the file is genuinely saved in UTF-8 encoding, not merely declared as such in the XML header.

---

Invalid TIN Formats

Tax Identification Number (TIN) errors are among the most frequent reasons for report rejection. Each jurisdiction enforces its own TIN format, length, and character rules, and many apply check-digit algorithms.

Common causes include:

• Country-specific format mismatch: A TIN that is valid in one Member State may not match the expected pattern for another. For example, a German IdNr is 11 digits, while an Italian Codice Fiscale is 16 alphanumeric characters.
• Failed checksum validation: A single transposed digit may cause the TIN to fail its check-digit algorithm, even if the length and character type appear correct.
• Stripped leading zeros: Numeric TINs may lose leading zeros during data import or storage if handled as integers rather than strings.

How to fix:

• Validate each TIN against the format rules published by the OECD or the relevant national authority before generating the XML.
• Store TINs as strings, not numbers, to preserve leading zeros.
• Apply country-specific check-digit algorithms where available.

---

Missing Required Fields

The DAC8 schema defines a number of mandatory elements. If any required field is absent or empty, the report may be rejected during validation.

Common missing elements include:

• MessageSpec errors: Missing or invalid MessageRefId, MessageTypeIndic, ReportingPeriod, or SendingCompanyIN.
• Reportable User details: Missing Name, Address, or TIN elements where required.
• Transaction-level fields: Missing TransactionType, AssetType, or amount fields.

How to fix:

• Compare your generated XML against the official XSD element by element, checking that every mandatory element is present.
• Pay attention to element ordering. XML schemas are typically order-sensitive, and an element placed in the wrong position may trigger a "missing element" error even though it exists in the file.
• Use a validation tool that reports all errors at once, rather than fixing them one at a time.

---

Data Consistency Issues

Even when individual fields pass validation, the report may still be rejected if the data is internally inconsistent.

Common causes include:

• Mismatched totals: Aggregate values that do not match the sum of the underlying individual transaction records.
• Duplicate records: Multiple records sharing the same DocRefId, or the same user-transaction combination reported more than once within the same period.
• Contradictory fields: A user declared as resident in one jurisdiction with a TIN issued by a different jurisdiction, without a valid explanation or multi-residency structure.

How to fix:

• Reconcile aggregate totals against individual records before generating the XML.
• Ensure every DocRefId is unique across the entire submission.
• Cross-check user jurisdiction declarations against the TINs and addresses provided.

---

Incorrect Reporting Period

Submitting data for the wrong reporting period, or submitting overlapping data that conflicts with a previous filing, may lead to rejection.

Common causes include:

• Wrong dates in ReportingPeriod: Using an incorrect start or end date, or referencing a period that does not align with the tax authority's expected reporting calendar.
• Overlapping periods: Submitting a report that covers dates already included in a previously accepted submission without using the proper correction or amendment mechanism.
• Timezone-related date shifts: Transactions occurring near midnight UTC may be assigned to the wrong reporting day depending on how timestamps are processed.

How to fix:

• Confirm the exact reporting period boundaries required by the relevant tax authority. These should be consistent with the ReportingPeriod element format in the schema (typically a full calendar year expressed as a date).
• If you need to update data for a period that has already been filed, use the correction or void mechanism rather than resubmitting the original period.
• Standardize all transaction timestamps to UTC before determining which reporting period they fall into.

---

How to Resubmit After Rejection

If your report is rejected, the resubmission process should generally follow these steps:

1. Review the rejection notice. Tax authorities typically provide an error log or status file indicating which validations failed. Read this carefully before making changes.
2. Identify and fix the root cause. Address the specific errors cited in the rejection notice. Avoid making unrelated changes to the file at the same time, as this may introduce new issues.
3. Validate locally. Run the corrected file through XSD validation and any additional checks before resubmitting.
4. Use the same MessageRefId or generate a new one as required. Some tax authorities expect the resubmission to use a new MessageRefId, while others may expect the same one. Consult the relevant authority's guidance on this point.
5. Resubmit through the original channel. Use the same portal or submission mechanism as the original filing.
6. Confirm acceptance. Monitor for an acknowledgment receipt or status update to verify the resubmission was accepted.

> Note: Some Member States may impose a limited number of resubmission attempts or a deadline by which corrections must be received. Check the applicable rules for your jurisdiction.

---

Prevention Checklist

Taking these steps before each submission may help you avoid the most common rejection reasons:

• [ ] Validate the XML against the current official XSD before uploading.
• [ ] Confirm the correct XML namespace and schema version for the reporting period.
• [ ] Verify that all mandatory fields are present and populated.
• [ ] Run country-specific TIN format and check-digit validations for every Reportable User.
• [ ] Ensure all DocRefId values are unique within the submission.
• [ ] Reconcile aggregate totals against the sum of individual transaction records.
• [ ] Confirm the ReportingPeriod matches the tax authority's expected dates.
• [ ] Check that the file is saved in UTF-8 encoding.
• [ ] Test the submission in a sandbox or test environment, if one is available from the tax authority.
• [ ] Maintain an internal log of all validation errors and their resolutions for audit purposes.

---

Disclaimer

This article is intended as general technical guidance for organizations preparing DAC8 reports. It should not be treated as legal or tax advice. Rejection reasons, validation rules, and resubmission procedures may differ across EU Member States and may change over time as schemas are updated. Always consult the relevant national tax authority's official documentation and, where appropriate, seek professional advice before acting on any information provided here.