ERP Rescue, South Africa

The opening questions in a South African rescue

Before anything gets fixed, everyone has to agree on what is actually wrong. Status reports in a troubled project tend to describe intentions, so I build the picture from conversations, documents and the system itself.

The early questions are simple but revealing:

• Which system is the real book of record today, for sales, purchases, stock and the ledger?
• Which VAT periods have been submitted since go-live, and from which source were they prepared?
• How are payroll journals from the payroll provider being posted, and has anyone reconciled them?
• What happened at each site during power or network interruptions since go-live, and what was captured twice or not at all?
• What did the contract and statement of work include, and which open items does the implementer regard as new requests?
• Who on the client side has authority to make design decisions, and how quickly are they made?

I speak with each party separately so people can be candid, then test the core flows myself in the system. The result is one written picture of where the project stands, shared with directors and, in a suitable form, with the implementer. Fault is not the point of this stage. My ERP recovery service page describes the approach outside any one country.

Protecting VAT periods, payroll and the month-end close

Recovery cannot put SARS submissions, salaries or supplier payments at risk. So the first practical step is a holding pattern: clear rules for what the business relies on while the system is being fixed.

With your financial director and accountant, I agree which system each VAT period will be prepared from, how sales and purchases captured in both systems will be identified and excluded from double counting, and what reconciliation will be done before each submission. Where a past period may need correcting, your accountant or registered tax practitioner decides how; I document what the system shows so they can decide quickly.

Payroll usually comes from an external provider, which keeps salaries safe even when the ERP is unsettled. The risk is in the posting: journals mapped to the wrong accounts or cost centers, or posted to one system and not the other. I check the mapping and agree a monthly payroll-to-ledger reconciliation.

For month-end, I give finance a short recovery checklist covering bank, debtors, creditors, stock, intercompany balances, payroll and VAT control accounts. Closing one month cleanly in the new system, with figures the financial director is prepared to sign, is the clearest signal to the whole business that the recovery is real. More on this period appears on my go-live support page.

Fixing data that went wrong in the move off Sage or Pastel

When a South African go-live includes a migration from Sage, Pastel, Xero or QuickBooks, a rushed load leaves marks that spread through every report. Typical damage includes duplicate customers and suppliers, VAT numbers missing or attached to the wrong records, items without correct tax settings, opening balances that never matched the old ledger and stock quantities that were estimated rather than counted.

Supplier records need particular care. If classification data and supporting documents used for procurement and B-BBEE reporting were left behind or loaded inconsistently, spend reports from the new system cannot be relied on. I include that data in the repair scope, while scorecard decisions remain with your specialist advisors.

The repair runs in a fixed order so effort is not wasted. Reference data such as tax codes, accounts and branches comes first. Masters follow, then the opening position, then transactions posted since go-live, each batch checked by finance before the next begins. Where a correction affects VAT already submitted, your accountant decides the treatment.

As each area is repaired and trusted, the corresponding part of Sage or Pastel can be closed for new entries, which brings parallel running to a planned end rather than letting it fade out. The ERP migration checklist lists the controls that prevent the same problems in later phases.

Working through the problem with your implementer

A rescue does not automatically mean replacing the implementer. A team that knows your configuration, given a fair reset and clear decisions from your side, can often finish the job well. Changing teams brings its own learning curve and risk.

What usually has to change is how the work is defined and governed. I take every open issue and change request and sort it into four groups: in the signed scope, requested since, disputed and no longer wanted. That sorted list becomes the agenda for a working session with the implementer, where we agree what stable operation requires, what moves to a later stage, the acceptance test for each item and the named people on both sides. Disputed items are discussed against the documents, not memories.

Practical matters belong in the reset too. If the implementer bills in dollars, or the license is priced in dollars, the remaining budget in rand may look different from the original plan, and that should be acknowledged openly. If the implementer works from another region or country, response times and meeting hours need to be agreed.

Where the relationship has to end, plan the exit before giving notice. Get hold of admin logins, setup and custom code documentation, connector keys, the files used for migration and the full issue register before anything else. My client-side implementation support in South Africa can then continue with a new team.

Deciding the future of the project, and the contract questions

When compliance is protected and the facts are agreed, the directors can take the decision the whole rescue has been building toward. I prepare a short decision pack with three options, described by the work involved, the risk and the disruption to operations, without speculative cost or time figures.

• Continue with the existing system and scope on a rebaselined plan, where the system suits your trading model and the trouble came from planning, data or capacity.
• Re-scope to a core of finance, sales, purchasing and stock that works reliably across branches before adding point-of-sale, manufacturing or a second entity.
• Re-platform where hands-on testing shows the system cannot support your core processes, outage tolerance or branch structure without customization you would struggle to maintain.

Contracts shape what is possible. Before withholding a payment, issuing a notice or signing a revised statement of work, ask your attorney to review the agreement. I give them an organized fact file: the contracted scope, change history, what was delivered and accepted, and what remains open. Interpretation of the contract is theirs, not mine.

Nothing I recommend is influenced by vendor or implementer money: I accept neither commissions nor referral fees. Where the system runs but underdelivers, the ERP audit page for South Africa explains a calmer, structured review; the South Africa overview covers my wider work there.