Tax and SARS knowledge base
How do I submit third-party data to SARS through the HTTPS channel?
When should a reporting institution use the SARS HTTPS channel, and what must happen before its first submission?
Last reviewed:
Direct answer
The HTTPS channel is a secure bulk-submission route for institutions that must send third-party data to SARS. It is suited to files that are too large for manual capture on eFiling but do not require a dedicated Connect:Direct arrangement. Enrolment, technical testing and production submission are separate stages.
A successful upload is not the end of the process. The institution must retrieve and reconcile SARS response files, correct rejected records and retain evidence that the accepted population agrees to its source system.
What this means in practice
Start with the current business requirements specification for the data type. A file can upload successfully and still fail validation because a field, code, date or identifier does not meet that specification.
Assign responsibility for both the technical transfer and the tax-data reconciliation. This avoids a common gap where IT can prove that a file moved, but nobody confirms which records SARS accepted.
Step-by-step
- Confirm the reporting data type and submission period.
- Enrol the organisation and authorised users for third-party data services.
- Build the file to the current SARS business requirements specification.
- Validate identifiers, totals and mandatory fields before upload.
- Complete any required test submission before using production.
- Upload through the HTTPS channel and save the submission reference.
- Download the response files and separate accepted and rejected records.
- Correct rejected records through the same channel and reconcile the final accepted totals.
Documents and records to keep
- Channel enrolment confirmation and user-authority record.
- The source extract and final submitted file.
- Pre-submission validation and control totals.
- Upload reference, response files and rejection log.
- Correction files and final reconciliation sign-off.
Important limits and exceptions
Do not reuse an old file layout without checking its effective date. SARS can change specifications, validation rules and reporting dates.
Do not treat transport encryption as proof that the contents are correct. Security, file validity and tax-data accuracy are different controls.
When to get tailored advice
Get help where the institution is changing channels, submitting several certificate types, has unresolved rejection codes or cannot reconcile accepted totals to its ledger or member system.