DAC8 Report Submission: Formats, Channels, and Confirmation

Once your DAC8 report has been generated and validated, the final step is submission to your national tax authority. This guide covers the practical aspects of how to submit, what formats and channels to expect, file size considerations, how acknowledgement processes typically work, and what to do if you need to resubmit.

> Disclaimer: Submission procedures vary significantly by EU Member State. The information below reflects general expectations based on the DAC8 framework and comparable reporting regimes (such as CRS and DAC6). Always check with your national tax authority for the specific submission process, channel, and format requirements that apply in your jurisdiction.

Report Format

XML as the Standard

DAC8 reports are expected to be submitted in XML format, conforming to an official XML schema (XSD) defined by the European Commission or adapted by individual Member States. This is consistent with other EU tax information exchange frameworks.

Key format requirements typically include:

• XML version: Usually XML 1.0
• Encoding: UTF-8 is the standard encoding for most tax reporting XML schemas
• Schema compliance: The XML file must validate against the official XSD without errors
• Namespace declarations: Ensure the correct XML namespaces are declared in the root element
• Character restrictions: Some characters may need to be escaped or may not be permitted (e.g., certain control characters)

Schema Versions

Be aware that the XML schema may be updated between reporting periods. Before generating your report:

1. Confirm the current schema version with your national tax authority
2. Check for any errata or corrections published since the schema was released
3. Test your report against the correct version of the schema
4. If your authority has published national extensions or modifications to the EU schema, incorporate those

File Naming Conventions

Some tax authorities may specify a file naming convention for submitted reports. Common conventions include elements such as:

• Country code of the sender
• Reporting entity identifier
• Reporting period (year)
• Message type (new, corrective, void)
• Sequence number (if multiple files are submitted)
• File extension (.xml)

Example: DE_RCASP123456_2026_NEW_001.xml

Check your national tax authority's guidance for specific file naming requirements, as non-compliant file names may cause rejection in some systems.

Submission Channels

The specific channel for submitting DAC8 reports depends on your Member State. Based on precedent from CRS, FATCA, and DAC6 reporting, the following channels are commonly used:

1. Secure Online Portal

Many tax authorities provide a web-based portal for uploading XML reports. This is often the most common channel for smaller reporting entities.

Typical process:

1. Log in to the tax authority's secure portal using your registered credentials
2. Navigate to the DAC8 or international tax reporting section
3. Upload your XML file through the designated form
4. Receive an on-screen confirmation or reference number
5. Download any receipts or acknowledgement documents provided

Considerations:

• Portals may have file size limits (commonly 5 MB to 100 MB, but this varies)
• Session timeouts may affect large uploads
• Some portals require specific browser versions or security plugins
• Multi-factor authentication is commonly required

2. Secure File Transfer Protocol (SFTP)

For larger reporting entities or those submitting multiple files, SFTP is a common channel.

Typical process:

1. Apply for SFTP access through your tax authority (this may require a separate registration)
2. Receive SFTP credentials and connection details (host, port, directory)
3. Install or configure an SFTP client
4. Upload your XML file(s) to the designated directory
5. Monitor for acknowledgement files in a response directory

Considerations:

• SFTP credentials should be managed securely and rotated periodically
• Some authorities may use PGP encryption for files in transit
• File size limits may be higher than portal uploads but are still likely to exist
• Connectivity testing should be performed well before the submission deadline

3. API-Based Submission

Some Member States may offer RESTful or SOAP-based APIs for automated report submission. This is typically the most suitable option for large platforms with automated reporting pipelines.

Typical process:

1. Register for API access and obtain API keys or certificates
2. Integrate the API into your reporting system
3. Submit the XML report programmatically via the API
4. Receive a synchronous or asynchronous response with status and reference number

Considerations:

• APIs may have rate limits and payload size restrictions
• Authentication may use certificates, API keys, OAuth, or a combination
• Error handling should account for network failures, timeouts, and server-side rejections
• API documentation and sandbox environments may be provided for testing

4. Electronic Data Interchange (EDI)

Some jurisdictions may support EDI channels for high-volume reporters. This is less common for DAC8 but may be available in certain Member States.

5. Physical Media (Rare)

In exceptional cases, some authorities may accept reports on encrypted physical media (USB drives, DVDs). This is uncommon and generally only used as a fallback or for authorities with limited digital infrastructure.

File Size Limits and Splitting

If your report exceeds the file size limit imposed by your submission channel, you will need to split it into multiple files.

Splitting Strategies

• Split by user: Distribute Reportable Users across multiple files. Each file should be a complete, valid XML document with its own MessageSpec header.
• Split by jurisdiction: If you report to multiple receiving countries, create separate files per receiving jurisdiction.
• Sequential numbering: If splitting is necessary, use sequential message reference IDs and file names to indicate the ordering (e.g., file 1 of 3, file 2 of 3, etc.).

Important Rules When Splitting

• Each split file must be independently valid against the XSD
• Do not split a single user's data across multiple files
• Each file must have a unique message reference ID
• Ensure that all split files are submitted as a complete set; partial submissions may trigger errors or queries

Pre-Submission Testing

Before submitting your actual report, take advantage of any testing facilities provided by your tax authority:

Sandbox or Test Environment

• Many tax authorities offer a test environment where you can submit sample reports and receive validation feedback without it being treated as a live submission
• Test submissions help identify formatting issues, schema compliance problems, and connectivity issues
• Submit test files with realistic (but anonymized or fictitious) data to exercise your full pipeline

Validation Tools

• Some authorities provide downloadable or online validation tools that check your XML against the schema and business rules
• Third-party validation tools may also be available, though you should always confirm compliance against the official schema
• Run both schema validation (structural compliance) and business rule validation (logical compliance) before submission

The Submission Process: Step by Step

Step 1: Final Pre-Submission Checks

Before uploading or transmitting your report:

• [ ] XML validates against the current official schema
• [ ] File encoding is UTF-8
• [ ] File name follows the required convention (if applicable)
• [ ] File size is within the channel's limit (split if necessary)
• [ ] Message reference ID is unique and has not been used in previous submissions
• [ ] Reporting period is correct
• [ ] All mandatory elements are present

Step 2: Authenticate and Connect

• Log in to the portal, establish the SFTP connection, or authenticate to the API
• Verify that your credentials are valid and not expired
• Ensure your session is secure (HTTPS, SFTP, or equivalent encryption)

Step 3: Upload or Transmit

• Upload the XML file through the designated method
• For portal uploads: wait for the upload to complete fully before closing the browser
• For SFTP: verify the file transfer completed successfully (check file size on the remote server if possible)
• For API: handle the response and check for success/error status codes

Step 4: Receive Confirmation

• Record the immediate confirmation, receipt number, or HTTP response code
• Download or save any on-screen confirmation messages
• Note the timestamp of submission

Step 5: Archive

• Save a copy of the exact file that was submitted
• Record the submission channel, timestamp, confirmation reference, and the person who performed the submission
• Store this information in your compliance records

Acknowledgement Procedures

After submission, the tax authority will typically process your report and return an acknowledgement. The acknowledgement process may work as follows:

Immediate Acknowledgement

Some channels provide an immediate response upon upload, confirming that the file was received. This is usually a technical acknowledgement only. It confirms receipt but does not necessarily confirm that the content of the report is valid.

Processing Acknowledgement

After the tax authority processes the report (which may take hours, days, or in some cases weeks), you should receive a processing acknowledgement that indicates:

• Accepted: The report passed all validation checks and has been accepted
• Accepted with warnings: The report was accepted but contains minor issues that you may want to correct
• Rejected: The report failed validation and must be corrected and resubmitted

How Acknowledgements Are Delivered

Depending on the channel, acknowledgements may be delivered via:

• A status update in the online portal
• An acknowledgement file deposited in your SFTP response directory
• An API callback or polling endpoint
• Email notification (often as a supplement to one of the above)

What to Do with the Acknowledgement

• Accepted: Archive the acknowledgement alongside your submitted file. No further action needed for this period unless corrections are identified later.
• Accepted with warnings: Review the warnings. If they indicate data quality issues, consider filing a corrective report.
• Rejected: Analyze the rejection reasons, correct the issues, and resubmit. See "Resubmission" below.

Resubmission and Corrections

If your report is rejected, or if you discover errors after submission, you will need to submit a corrective report.

Types of Follow-Up Submissions

1. Corrective report: Replaces or amends specific data in a previously accepted report. The XML typically uses a "corrective" message type indicator and references the original message.
2. Void/deletion report: Cancels a previously submitted report or specific records within it. Used when data was reported in error.
3. New replacement: In some implementations, you may need to void the original and submit an entirely new report.

Correction Process

1. Identify the specific errors or records that need correction
2. Prepare a corrective XML file using the appropriate message type
3. Reference the original message ID being corrected
4. Validate the corrective file against the schema
5. Submit through the same channel as the original report
6. Monitor for acknowledgement of the corrective submission

Common Rejection Reasons

• Schema validation failure (malformed XML, missing elements)
• Invalid or missing TINs
• Incorrect reporting period
• Duplicate message reference ID
• File encoding issues (not UTF-8)
• Inconsistent or missing financial data
• Unknown entity identifier in the report header

Resubmission Deadlines

Check whether your national tax authority imposes a deadline for resubmission after rejection. Some authorities may allow a defined number of days (e.g., 30 days) to correct and resubmit before the rejected submission is treated as a missed filing.

Submission Calendar and Planning

To avoid last-minute issues, plan your submission timeline:

Milestone	Suggested Timing
Schema and channel confirmed	3-4 months before deadline
Test submission completed	2-3 months before deadline
Data extraction and aggregation	6-8 weeks before deadline
XML generation and validation	4-6 weeks before deadline
Internal review and sign-off	2-4 weeks before deadline
Submission	At least 1-2 weeks before deadline
Acknowledgement monitoring	Ongoing after submission

Submitting well before the deadline gives you time to handle rejections and resubmissions without missing the filing date.

Submission Checklist

• [ ] Confirmed the correct submission channel for your jurisdiction
• [ ] Obtained and tested access credentials for the submission channel
• [ ] Confirmed the current XML schema version
• [ ] Confirmed any file naming conventions
• [ ] Confirmed file size limits and splitting requirements
• [ ] Completed test submission (if sandbox available)
• [ ] Final report generated, validated, and internally approved
• [ ] Report submitted before the deadline
• [ ] Immediate confirmation received and saved
• [ ] Processing acknowledgement received (accepted, warnings, or rejected)
• [ ] If rejected: correction prepared and resubmitted within allowed timeframe
• [ ] All submission documentation archived in compliance records

Summary

Submitting a DAC8 report involves more than just uploading a file. You need to confirm the correct format and schema, identify and test your submission channel, manage file size limitations, track acknowledgements, and be prepared to handle rejections and corrections. Building a repeatable submission process with clear checklists and timelines will ensure that each reporting period goes more smoothly than the last.

This article is for informational purposes only and does not constitute legal or tax advice. Submission procedures vary by Member State. Check with your national tax authority for the specific requirements applicable in your jurisdiction.