ERP Requirements, South Africa

What sits inside a South African ERP specification

The BRD tells the story of the business. The specification is shorter on story and stricter on commitment: each line says what the system must do and how that will be proven. For a South African company, the document I prepare tends to contain:

• Front matter: who wrote, reviewed and approved each version, plus a history of what changed between versions.
• Footprint: entities, branches, depots, stores and any site that runs on generator or inverter power during outages.
• Process chapters: sales and collections, purchasing and imports, stock and transfers, production or projects where relevant, and month-end close in rand.
• Statutory register: VAT, payroll interface, retention and reporting lines your advisor confirms.
• B-BBEE reporting lines: outputs your verification advisors need.
• Behavioral requirements: availability, hosting, POPIA, access and audit trail.
• Interfaces, migration and a report catalog listing the columns each report must show.

Every line carries an ID, an owner, a site flag, a priority and trace references. Discovery for those chapters, including the B-BBEE data dictionary and the outage task analysis, is a separate piece of work: see ERP business analyst in South Africa. The general method is on ERP BRD consulting.

Statutory and B-BBEE lines your advisors can sign

The register records statements your tax advisor, payroll provider or B-BBEE verification advisor has confirmed. I supply wording precise enough to test, never the tax or empowerment advice itself. Examples of the style:

• Tax invoices carry the content your advisor says is required for the value involved, and an invoice cannot be issued while a required customer field is blank.
• Figures for the VAT return can be produced per period and traced to the documents behind each total.
• Import VAT paid through the clearing agent can be linked to the shipment and the supporting customs documents.
• Payroll journals from the payroll provider, including PAYE, UIF and SDL amounts, post to agreed accounts without manual re-keying.
• A procurement report shows spend for any period your verification advisors choose, grouped by the supplier attributes they specify.
• Accounting and tax records can be found and read for as long as the law requires, as your advisor interprets it.

SARS has signaled a move toward more digital reporting, so a few readiness lines ask for structured invoice data and an integration route, without guessing at the final rules. Most of these lines carry a must tag, and each records who confirmed it.

Availability, hosting and access written as commitments

For many South African businesses, the risk of load-shedding and unstable connectivity is a planning condition, not an IT footnote. In the specification, I turn the outage analysis into lines a bidder has to answer directly:

• Continuity by task: which activities, such as counter sales, dispatch or goods receipt, must continue when a site loses power or its link, and the tolerance the business has agreed for each.
• Catch-up behavior: how work captured offline returns to the central system, how conflicts are flagged, and who reviews them.
• Hosting: whether the system is cloud-hosted so one site's outage does not stop others, where production data and backups are stored, and whether that location affects POPIA obligations as your advisor reads them.
• Personal data: limits on who sees employee and customer details, masking of ID numbers in exports and removal when retention ends.
• Access and audit trail: roles by entity and branch, approval for supplier bank changes and a log of edits to masters and posted entries.
• Performance and support: month-end behavior and support during South African business hours.

Site power backup and network design remain your IT team's decisions; the specification states what the ERP must do around them.

Interfaces, migration, priorities and the trace chain

Interfaces are numbered lines of their own. South African entries commonly cover payroll journals, bank payment and statement files, clearing agent data for imports, point-of-sale or webstore sales and any group reporting pack. For every one, the line names the sending and receiving system, the schedule, the accountable person and the fallback if the feed breaks or coincides with an outage. More on the method is at ERP integration.

The migration chapter states what leaves Sage, Pastel or another package: masters, open debtors and creditors, stock by location, fixed asset registers and how much history. It names who signs off each reconciliation.

Priority uses four tags. A must blocks go-live. A should can wait behind a documented workaround. A could adds value but is optional. Later is recorded for a future phase. Every must needs a written reason, which keeps the tender focused.

Trace columns then connect every requirement with its selection demo, the bidder's written answer, the matching design decision, a scripted test and the UAT sign-off. When someone asks whether offline capture was ever promised, the chain answers in minutes rather than meetings. My ERP testing and UAT page shows how those scripts are run.

Using the document in tenders, and gaps that create risk

In an ERP RFP or tender, each bidder marks every line as native, configured, custom-built, dependent on an add-on or not offered, and explains the answer. After the decision, the signed baseline and the winning response form a contract annex, while each later amendment needs a logged request, an impact note and a named approver. The ERP selection consultant page for South Africa covers how responses are scored.

When reviewing an existing South African specification, I check first for gaps like these, each a risk to cost, compliance or operations:

• Availability left to a generic uptime clause, with nothing on what branches do during load-shedding.
• B-BBEE reporting described as a wish, with no fields, periods or owner.
• Payroll assumed to sit inside the ERP when it actually runs with an outside provider.
• Import costs and foreign currency purchasing missing from the purchasing chapter.
• Hosting location never asked, so POPIA questions surface after signing.
• Support terms silent on who pays for changes when SARS or payroll rules move.

Beyond specifications, my remote ERP work for this market is summarized on the South Africa ERP consulting page.