How can duplicate employee tax certificates arise during payroll migration?

A payroll migration transfers a reporting history

Moving payroll systems is not only a transfer of employee names and salary balances. The business also needs to preserve which earnings were processed, which certificates were generated and which records were submitted to SARS. Losing that history can cause correct data to be reported more than once.

Before migration, identify the employer, tax year and cutover date. Decide which system holds the authoritative record for each period and which system will generate the reconciliation submission. If both providers assume they own the full year, overlapping certificates can result.

Keep the migration plan, exports and agreed responsibilities. A new employee number in the destination system should still be traceable to the person’s old record. A fresh screen does not mean the underlying employee or tax history has started again.

Recognise common duplication patterns

These are diagnostic possibilities. Establish the actual sequence using files and official responses rather than assuming the software created an error merely because migration occurred.

Several certificates for one person are not automatically wrong

An employee may have records from different employers or legitimate separate employment periods. The same name appearing twice is not enough to identify a duplicate. Compare employer reference, employee identity, certificate number, period and the underlying remuneration.

Also distinguish a duplicate employee profile from a duplicate submitted certificate. Merging local employee records may improve administration without removing a certificate already received by SARS. Conversely, two local drafts may not have created any duplication at SARS if only one was submitted.

The SARS reconciliation guidance links declarations and employee certificates. The review should establish which records belong in the correct certificate set, not simply reduce the count until it resembles the current headcount.

Keep leavers and historical records available. Deleting a former employee from the new payroll because they are no longer employed can remove evidence needed for the annual reconciliation and conceal a mismatch in the migrated totals.

Prepare an employee and period cutover map

Create a mapping between old payroll identifiers and new identifiers using reliable identity information. Check names, identity or passport details and tax references carefully. Do not create another tax registration merely because the new system cannot find the existing reference.

Record the last period processed in the old system and the first period in the new one. Explain whether opening balances represent cumulative year-to-date amounts or transactions that will be generated again. Those two designs need different checks.

Reconcile remuneration and deductions at employee level, then reconcile the totals for the employer. Include irregular runs, bonuses, reversals and adjustments outside the normal salary cycle. A successful file import only confirms that data was accepted by the application; it does not prove that the migration is financially correct.

Have the old provider confirm what it has already submitted and what remains outstanding. Agree who handles later corrections for earlier periods. Keep this responsibility explicit so both providers do not independently resubmit the same history.

Check the official submission history

Obtain the relevant EMP501 submissions, certificate history and processing responses. Compare them with the old and new payroll exports. Identify the employer and reconciliation period on every record so an interim submission is not confused with an annual one.

The current SARS e@syFile page discusses the retrieval of certificate history and current software changes. Use the official guide for the version being used. Old screenshots and menu instructions may describe a retired application.

If the application shows a pending submission or an unexpected status, investigate the exact message before sending the same data again. Save the response and use the supported enquiry or correction route. Repeatedly pressing submit is not a reliable way to establish whether the earlier file was processed.

Keep the submitted file and acknowledgement together. A filename alone cannot prove what was transmitted, especially if a later export overwrote a file with the same name.

Reconcile before deciding what to cancel or replace

Prepare a schedule of the suspected duplicates showing the employee, certificate references, periods, amounts and reason each appears duplicated. Link each row to payroll evidence. Distinguish the correct record from any superseded or erroneous record.

Check the effect on EMP501 totals and the employer account. Removing one certificate may change the reconciliation, while correcting a name may leave the totals unchanged. The remedy should follow the actual error rather than a blanket instruction to delete every repeated employee.

The SARS duplicate-submission FAQ explains that overlapping submission information can result in duplicate certificates. Its older screen sequence should be read alongside current application guidance. Confirm whether the case needs correction, cancellation, a supported resubmission or official assistance.

Preserve backups or exports before changes. Do not erase the only copy of the old payroll database to make the new file appear clean. The historical evidence is what allows the business to explain why a correction is justified.

A fictional example: duplicated opening balances

A fictional employer moves payroll after June. The new system receives cumulative earnings for March to June as opening balances. A separate import also loads those four months as transactions, and the annual certificate calculation includes both.

The employer should compare each employee’s cumulative amounts with the old system and identify exactly where the same earnings appear twice. It then corrects the migration through the supported payroll process and checks any certificates or reconciliations already submitted.

If the duplicate amounts existed only in a local draft, the official correction task may differ from a case where both certificate sets reached SARS. The example illustrates why the submission history matters. It does not prescribe one universal cancellation sequence for every payroll product.

Use current tools without losing the evidence

The current e@syFile FAQs and release guidance should be checked before technical changes. Software migration and payroll-data migration are related tasks but not necessarily the same operation.

Follow supported backup, retrieval and installation instructions for the actual version. Keep a record of which application and file were used for the submission. If technical help is needed, provide the precise message, employer period and steps already taken without exposing passwords or unnecessary employee information.

After the correction, review the processed result and affected certificate history. Inform employees which certificate is current where an earlier document was replaced. Do not assume that fixing the local database automatically updates a certificate already downloaded or used in an employee’s personal return.

Complete a migration acceptance check

1. Confirm employer identity and the cutover period.
2. Reconcile employee identity mappings and opening balances.
3. Compare the complete certificate set with payroll totals.
4. Check prior official submissions and avoid overlapping reporting.
5. Use the appropriate supported correction process where needed.
6. Verify processing results and communicate replacement records clearly.

For Vatco’s reconciliation support, provide both payroll exports, the cutover plan and submission history. The earlier-period correction guide helps trace the consequences. A complete migration leaves the business with one explainable reporting history, including genuine separate certificates and properly documented corrections.