Tax and SARS knowledge base
How do I manage a submitted third-party data file on SARS eFiling?
What should an institution do after a third-party-data file has been uploaded to SARS?
Last reviewed:
Direct answer
Monitor the file through processing, retrieve the SARS response, identify accepted and rejected records, and reconcile the result to the source population. A submitted status proves transfer, while an accepted result proves that SARS processed the records subject to its validations.
Keep the original file immutable. Corrections should be controlled as new versions with their own submission and response evidence.
What this means in practice
Use a rejection register that assigns an owner and reason to each failed record. This prevents repeated uploads of the same unresolved error.
Reconcile by both record count and monetary totals where the data type contains amounts. A count-only check can miss a material value error.
Step-by-step
- Record the upload reference, filename, data type and period.
- Monitor processing until a final response is available.
- Download and preserve every response file.
- Map accepted and rejected records to the source extract.
- Investigate each rejection code against the current specification.
- Correct the source system before creating a replacement file.
- Submit corrections through the proper channel.
- Sign off the final accepted count and value reconciliation.
Documents and records to keep
- Immutable original and correction files.
- Submission references and response files.
- Rejected-record register.
- Source-system correction evidence.
- Final count and value reconciliation.
Important limits and exceptions
Do not overwrite response files or reuse filenames without version control.
A technical rejection may expose a broader master-data problem. Fixing only the exported row can allow the error to recur.
When to get tailored advice
Get help where rejection volumes are high, response files are missing, totals cannot be reconciled or the deadline passed before acceptance.