Corrections & Terminations — Agribantu Documentation

What this guide covers: what to do once you notice something wrong in a run that's already been approved, or when an employee leaves.

Part A

Why nothing gets edited in place

By the time a run is approved, people may already have been paid and figures may already have fed into statutory returns. So Payroll treats every correction as a brand-new, forward-dated event that adds a reversal and/or top-up on top of history — never a silent rewrite. This keeps your audit trail, your employees' payslips, and your SARS filings all consistent with what actually happened, in the order it happened.

Part B

Correcting one employee's figure

For a single mistake — say a remuneration line or a statutory amount was wrong for one person — open the run, click Explain on that employee, and look for Correction comparison. Click Compare corrected fact, pick the original line, and enter the correct total.

Enter the correct total, not the difference. The field is explicitly the corrected total amount, not a plus/minus delta — the server works out whether that means an increase or a decrease compared to the original, and schedules any money owed back as a "future-run recovery" automatically. If you type a delta by mistake, the resulting sign will be wrong and easy to miss (for example, an amount that should reduce what's owed showing up as increasing it) — always sanity-check the direction shown after saving against the real-world situation before moving on.

Example — Karoo Valley Farm

Thandiwe's September gross was recorded as R 6 500.00 but should have been R 6 800.00 because of a rate change that was captured a day late. On Correction comparison, you don't enter "+300" — you enter the corrected total, R 6 800.00, with a reason such as "Compensation rate update captured late; back-pay for September." The system works out the R 300.00 difference and its direction for you.

Note the system's own caveat here: PAYE relief is assessment-only for some corrections — meaning certain PAYE adjustments can't be recovered as actual cash from SARS through the employer, only reflected in the employee's eventual tax assessment. If a correction touches PAYE, read the on-screen explanation carefully before assuming money will simply come back to the business.

Part C

A full correction run

For something bigger than a single line — an entire run that needs redoing — a payroll run can be created with Type: Correction instead of Regular/Off-cycle, referencing which run it corrects and a required correction reason. Architecturally this is never a retroactive edit either: it's simply another forward-dated payroll event, and its effect shows up as "Corrections" lines on the affected payslips (see Payslips & Paying People — Part E).

If you don't see a way to pick "Correction" as a run type from the normal Create-run dialog, this path may not yet be exposed for self-service in your version of the interface — contact Agribantu support rather than trying to force it through the per-employee Correction comparison tool in Part B for a whole-run-sized problem.

Part D

Advanced retro corrections — specialist territory

A small set of tools exist for correcting historic ETI determinations (an employee's ETI opening balance, or "continuity membership" across employment gaps) and historic termination statutory treatment. These always require reviewing a full, server-computed impact preview — affected calculations, accounts, filing and refund blockers — before you're allowed to type a reason and apply the change, and they carry hard warnings (for example, "Interval surgery") because of how deep their downstream effects run into ETI eligibility, filings and refunds.

Treat these as legal/compliance tools rather than everyday corrections. If you think you need one, involve your payroll administrator or accountant rather than working through it alone for the first time.

Part E

Terminations

When an employee leaves, open their page in Employee readiness — once a termination determination exists, a Create termination settlement button appears. It asks only for the facts you actually attest to:

Field	What to enter
Settlement pay period & payment date	When the final settlement is paid.
Attested unpaid remuneration	Any outstanding pay owed, with a reason.
Severance tax classification	Plus a bound tax directive ID, if SARS issued one for this severance.
Extended-hours arrears	Amount, reason, tax year and directive ID, if applicable.
Other termination lump sum	Amount, reason and directive ID, if applicable.

You must tick a confirmation: "I confirm the attested facts and understand that the server will derive and freeze the settlement." That's a deliberate design choice — notice pay, leave payout and severance amounts are calculated automatically by the server from the determination; you only enter the residual, explicitly-attested facts above it can't know on its own (like a directive number SARS issued directly to you).

Troubleshooting

Troubleshooting & FAQ

I entered the difference instead of the corrected total by mistake.

Open Correction comparison again and re-enter the true corrected total — the system will work out a new correction on top. Always re-read the resulting increase/decrease direction shown on screen against what actually happened before moving on.

Can I just delete an approved run and start over?

No — approved runs, and any payslips/returns/postings built on them, are never deleted. Use a correction run (Part C) or a per-employee correction (Part B) instead.

A retro-correction screen is asking me to review an "impact hash" — is that normal?

Yes, for the advanced ETI/termination tools in Part D — it's a fingerprint of the exact plan you reviewed, so you can't accidentally apply a different plan than the one you confirmed. This is intentionally hard to click through by accident.