Tax and SARS knowledge base
Why did SARS reject my Country-by-Country XML file?
Why did SARS reject my Country-by-Country XML file?
Last reviewed:
Direct answer
SARS's current Country-by-Country guide includes separate sections on the OECD CbC XML Schema, XML upload, eFiling error handling and correction of an XML file. A rejection must be handled from the exact SARS message and the submitted file version. Preserve the evidence, identify whether the issue is technical, declarative or access-related, correct the underlying problem and follow the applicable correction route.
There is no safe universal “fix and re-upload” answer. The right action depends on the error message, filing status and current SARS eFiling instructions.
What this means in practice
An XML rejection may arise before a report is accepted, during an upload, after a declaration step or while an eFiling user is trying to access the correct case. Start by preserving the original XML file exactly as submitted. Make a copy for investigation. Record its name, version, creation time, source-system release, submission reference and the full text of every SARS error message.
SARS's guide has dedicated sections for error handling on eFiling and for correction of the XML file. That is important because technical validation and correction administration are separate controls. Do not overwrite a rejected file in shared storage or amend it without a change log. A changed file may require data-owner sign-off as well as technical validation.
Step-by-step
- Capture the SARS rejection evidence. Save the error message, code if displayed, screenshots, submission reference, status and the date and time. Preserve SARS correspondence too.
- Freeze the original file. Calculate or record a version identifier and restrict editing. Copy it into a controlled working location rather than replacing the original submission artefact.
- Confirm the reporting period, reporting entity and associated CBC01 declaration. Check whether the error may result from the wrong case, wrong eFiling profile or a mismatch between the XML and the declaration.
- Consult the current SARS guide, including its OECD XML Schema, upload and eFiling error-handling sections. Match the error to the documented requirement, rather than relying on an old software message or a generic internet answer.
- Correct the underlying source data and file in a controlled environment. Record every change and secure approval from the responsible data owner. Validate the corrected file before it is presented for submission.
- Follow the guide's XML correction or eFiling process. Check the current case status and do not submit a duplicate report simply because the original result is unclear.
- Verify the final outcome. SARS's guide includes checking whether documents were submitted successfully. Save the final acknowledgement and reconcile the accepted version to the approved source data.
Documents and records to keep
- Original and corrected XML files, each with version history.
- eFiling error messages, acknowledgements and case references.
- Data reconciliation and technical validation output.
- CBC01 information and reporting-entity confirmation.
- Internal approval of every corrective change.
Important limits and exceptions
A schema-compliant XML file can still be wrong in substance. Conversely, an error that appears technical can result from selecting the wrong entity or reporting period. The technical team should not alter reporting facts without the responsible tax and data owners approving the change.
Do not invent a solution for an unfamiliar error code. SARS changes specifications and eFiling behaviour. Use the guide effective for the filing and verified SARS support channels where the official material does not resolve the problem.
When to get tailored advice
Seek specialist assistance for cross-border group changes, a report already accepted with a material error, uncertainty about a correction route or repeated rejection after controlled validation. Escalate immediately where a deadline is imminent, an identifier is inconsistent across files or confidential CbC data may have been exposed.