ERP Business Analyst South Africa

Turning VAT obligations into requirements a tester can check

A tender line such as "the system must be VAT compliant" sounds sensible but tells a vendor almost nothing, and every bidder will simply answer yes. What the project needs instead is a list of specific behaviors drawn from how your business actually trades. In my ERP requirements gathering work, that list tends to look like this:

• each item and service carries a default tax code, and only named roles can change it on a document
• supplier and customer records hold a VAT registration number where one applies, and posting rules depend on it
• credit notes always reference the original invoice and reverse its tax correctly
• import documents and clearing agent charges are captured so input tax can be supported later
• every figure on the VAT report can be drilled back to individual transactions

Your accountant or tax practitioner confirms the treatment behind each line, since tax advice sits outside my role, and I recommend checking the current SARS position with them before sign-off. What I add is a requirement that is precise, has an owner and has a matching test case, so the chosen system is proven against your scenarios rather than a generic checklist.

Supplier classification data as a formal requirement

When a company tracks its B-BBEE status, its procurement records must stand up to verification. In practice that data is often scattered: certificates and affidavits in mailboxes, expiry dates in a diary, spend totals compiled by hand. A new ERP will not fix this unless the requirement is written before anyone designs the supplier master.

I approach it as a data dictionary exercise. For each attribute your advisors say the measurement relies on, the BRD records the field name, the allowed values, who updates it, which document supports it and where that document is stored. It then describes the workflow around it: who is alerted when evidence nears expiry, whether new suppliers can be approved without it, and which report shows spend grouped by these attributes for a period your advisors define.

I keep a firm line here. Interpreting the codes and planning the scorecard belongs with your B-BBEE specialist. What I contribute is a clean specification of the information the system must hold, so whichever platform you pick can be tested against it. The same dictionary usually improves ordinary procurement too, because approval rules and preferred supplier lists rely on the same records. See also my ERP process mapping service.

Writing outage and connectivity needs into the BRD

Most requirement documents treat availability as an IT footnote. For a South African business with branches, warehouses or retail counters, scheduled power cuts and unstable links are an everyday operating condition, so I write them up as business requirements with the same weight as finance or stock.

The analysis starts with tasks, not technology. I ask each team which activities cannot stop: taking payment at a counter, picking and dispatching orders, receiving stock, capturing timesheets on site. For each one we note how long the business can tolerate the system being unreachable, what the manual fallback is, and how transactions recorded during the gap are entered or synchronized afterward without duplicates.

Those answers become concrete statements a vendor must respond to, for example that warehouse scanning queues transactions locally and flags conflicts after reconnection, or that a branch can print a delivery note from a cached copy. Hosting location and personal information handling under POPIA are noted alongside, as questions for your IT and legal advisors. In the fit-gap matrix, each platform's answer is tested rather than accepted from a brochure. Product behavior is covered in more depth on the South African pages for Odoo, Zoho, ERPNext and Dynamics 365.

Mapping branches, imports and the rand

Process mapping in South Africa often reveals that head office and the branches run quite different versions of the same process. One depot raises purchase orders, another buys on account and sends slips by email; one store counts stock weekly, another only at year end. Before writing requirements, I map each variant and agree with management which one becomes the standard and where genuine local differences must remain.

Foreign purchasing deserves its own map. Many businesses buy in dollars or euros while reporting in rand, so I trace an import from order through shipping, clearing, duties and freight to the final landed cost on the item. The BRD then states which costs are allocated, on what basis, at which exchange rate, and who approves adjustments. Your accountant decides the accounting policy; the requirement makes sure the ERP applies it consistently.

Each map is drawn in a simple notation that non-specialists can follow, reviewed in a recorded walkthrough and stored with the BRD. The ERP business analysis page explains the wider method, and the South Africa ERP consultant page covers selection and delivery beyond the analysis stage.

What you receive, and how language is handled

The analysis ends with a set of documents your team owns outright. A typical package holds as-is and to-be maps, the numbered register of requirements, a business requirements document, a supplier and customer data dictionary, a fit-gap matrix scoring every candidate product, a migration scope note covering what history leaves the old accounting package, and acceptance test scripts linked back to requirement numbers.

All documents are written in English, and the work itself is delivered in English. Where staff on the floor are more comfortable in another language, training notes or quick reference cards can be adapted by your own people, and I make sure the underlying steps are clear enough to translate without changing their meaning.

Because the work is remote, every workshop is recorded with your permission, drafts are shared in a common folder and comments are resolved in writing. That trail matters later. When an implementer questions why a requirement exists, or a new financial director joins halfway through, the reasoning is already documented rather than held in someone's memory. For a broader view of services in this market, start at the South Africa overview.