How does government buy software?
For most national and provincial departments, the road runs through SITA. The SITA Act 88 of 1998 establishes the State Information Technology Agency as government's central ICT agency, and for prescribed categories of ICT goods and services departments must procure through it. In practice that means two main routes: SITA's transversal term contracts — pre-negotiated framework contracts for commonly procured ICT (hardware, software licensing, services) that departments order against — and SITA-run RFB (request for bid) and RFQ (request for quotation) processes for specific requirements, published on SITA's procurement portal.
Not everything is SITA-mandatory. Some ICT acquisitions fall outside the prescribed categories and can be procured directly by the department under its own supply chain management framework — still a competitive, regulated process, but run by the department rather than the agency. And municipalities sit outside the SITA mandate altogether: local government procures under the Municipal Finance Management Act (MFMA) and each municipality's own supply chain management policy.
The practical takeaway for a software vendor: identify which route applies to your target buyer before investing in a bid. Whether you are responding to a SITA RFB, ordering against a transversal contract, or bidding directly to a department or municipality changes the documents, the timelines, and the room you have to negotiate.
What is the legal framework, in plain English?
Three layers sit above every government software deal. First, the Public Finance Management Act (PFMA): section 38 makes each department's accounting officer personally responsible for a procurement system that is fair, equitable, transparent, competitive and cost-effective. This is why government buyers cannot simply "do a deal" — every step has to survive audit scrutiny, and informal arrangements that would be normal in the private sector can render a contract irregular.
Second, the Preferential Procurement Policy Framework Act (PPPFA) and its regulations govern how bids are scored: the majority of points go to price, with the balance awarded for "specific goals" each organ of state defines in its tender documents under the current preferential procurement regulations — in practice often tied to B-BBEE status and transformation objectives. The detail of this regime has changed repeatedly, so the points breakdown in the actual bid documents is what matters. For software vendors, a competitive B-BBEE level is frequently a practical gate: technically compliant bids lose on points without it, which is why subcontracting and joint-venture structures are common in this market.
Third, the standard bid documents (SBD forms) that accompany every tender — declarations of interest, preference-point claims, tax compliance status, and certificates of independent bid determination. These are not formalities: signing them makes binding declarations about your business, your ownership, and how your bid was prepared, and a false or careless declaration can disqualify the bid, unwind the contract, or trigger restriction from doing business with the state. Read them as contractual commitments, because that is what they are.
The eight contract battlegrounds
Once you are past the tender mechanics, the contract itself is where government deals are won or lost commercially. These are the eight clauses where the state's framework and a software vendor's business model collide.
The GCC vs your EULA / SaaS terms
Government contracts on the state's paper: the general conditions of contract (GCC) plus special conditions drafted for the bid. Your standard EULA or SaaS terms — if they survive at all — are usually annexed and rank below the GCC in the order of precedence. Clauses the state's framework cannot accommodate (unilateral amendment rights, auto-renewal, foreign governing law) fall away. The fight is fought in the special conditions and the precedence clause, not by attaching your terms and hoping.
IP in customisations
Departments routinely demand ownership of anything developed under the contract — configurations, integrations, bespoke modules. Signed as drafted, an IP clause like this can hand the state rights in work that is inseparable from your core product. Define "deliverables" narrowly and carve out pre-existing IP, tools, and generic improvements before signature.
Keeping your product IP (licence, don't assign)
State contracting practice defaults towards the state owning IP produced on the state's budget. The drafting answer is to licence outcomes rather than assign the underlying software: the department gets a broad, perpetual licence to use the customised solution; you retain ownership of the product, the codebase, and the right to reuse generic components for other clients.
Liability and the cap fight
The state resists liability caps, and the GCC framework is not built around the limitation-of-liability architecture vendors rely on in private deals. Uncapped exposure on a multi-year ICT contract is a real balance-sheet risk. Caps, mutual exclusions of consequential loss, and insurance-backed limits must be negotiated into the special conditions — and priced if they cannot be.
Payment terms and the 30-day rule
National Treasury's framework under the PFMA requires departments to pay valid invoices within 30 days. The reality is that payment delays are common, and small vendors carry the cash-flow strain. Build in invoice-acceptance mechanics, escalation routes, and the right to claim mora interest on late payment — and budget working capital as if the 30 days will sometimes be missed.
Security, clearance and data sovereignty
Departments impose security vetting on personnel, departmental information-security policies on the solution, and increasingly strict positions on where data is hosted. POPIA applies alongside government security standards, and cloud-hosted products may face in-country hosting demands. Establish what the department's data classification requires before you price the bid.
Termination for convenience
The state typically reserves the right to terminate for convenience on notice — a right almost no private customer gets. For a software vendor that has priced implementation cost recovery over the contract term, early termination can strand unrecovered investment. Negotiate wind-down payments, licence-fee acceleration, or staged milestones that keep you whole if the contract ends early.
Audit and AGSA access rights
Government contracts carry audit rights well beyond commercial norms: the department, internal audit, and the Auditor-General of South Africa (AGSA) can access records relating to the contract. Open-book obligations can reach pricing models and subcontractor arrangements. Scope these rights to contract-related records and protect genuinely proprietary material (source code, third-party costs) with confidentiality carve-outs.
If your product is licensed rather than built to order, the structure of the underlying licence matters as much as the special conditions — see our guide to software licence agreements, and POPIA for tech companies for the data-protection layer that government security policies sit on top of.
What tendering mistakes do software vendors make?
Pricing the licence but not the GCC risk. Vendors price government bids off their commercial rate card, as if the contract were a private deal with extra paperwork. It isn't: uncapped liability exposure, termination for convenience, security and audit overheads, and the working-capital cost of payment delays all belong in the price. A bid that wins on a private-sector price and signs the state's terms unamended is frequently a loss-making contract.
Assuming negotiation happens after award. It largely doesn't. Procurement law restricts post-award changes to terms that affected the competitive evaluation, so the contract you bid on is substantially the contract you sign. The window to raise IP carve-outs, liability caps, and licensing structure is the bid-clarification stage — or in qualifications stated in the bid itself, with care, because unqualified compliance is often a scoring criterion.
Losing on technicalities. An unsigned SBD form, a lapsed tax clearance, a missing certified document — government bids are disqualified on administrative compliance before anyone evaluates the software. The fix is unglamorous: a compliance checklist run against the bid pack, by someone other than the person who assembled it, before submission.
Subcontracting or JV structures without clear IP splits. Teaming up is often how the preference-point and capacity requirements are met, but vendors regularly enter these structures on a one-page teaming letter. When the consortium builds something for the department, who owns the resulting IP — and who carries the contract's liability — must be settled between the partners in writing before the bid goes in, not after award when the leverage has evaporated.
Why does Pretoria matter here?
Government software deals are a Pretoria-centred practice area. SITA's head office is in Erasmuskloof; the national departments that buy software are headquartered across the city; and the Information Regulator — relevant whenever a government solution processes personal information — sits locally too. Bid-clarification briefings, negotiation sessions on special conditions, and meetings with departmental supply-chain and legal teams are routinely in-person affairs in this market.
MJ Kotze Inc is based in Pretoria — 15 minutes from SITA's head office. For a software vendor bidding into government, that proximity is a working advantage: attendance at compulsory briefings and clarification meetings without flights, and face-to-face negotiation when the special conditions are on the table. See our Pretoria software & technology law page for the broader local practice.
Frequently asked
Do I have to go through SITA to sell software to government?
For most national and provincial departments, yes in practice — the SITA Act 88 of 1998 makes SITA the procurement channel for prescribed categories of ICT goods and services, and departments procure those through SITA's tender processes or its transversal term contracts. Some ICT acquisitions fall outside the mandatory categories and can be procured directly by the department under its own supply chain management rules. Municipalities are different: SITA's mandate does not extend to local government, which procures under the MFMA and its own SCM policies.
Can I negotiate government contract terms?
Less than in the private sector, but more than most vendors assume. The GCC itself is effectively fixed, and procurement law restricts post-award renegotiation of terms that affected the competitive evaluation. The movement happens in the special conditions: IP carve-outs, liability caps, payment mechanics, and licensing structure can often be addressed there — but the time to raise them is at bid-clarification stage or in the bid itself, not after award.
Who owns the IP in customisations built for a department?
Whatever the contract says — and the state's starting position is usually that it owns IP developed under the contract. If the clause is signed as drafted, the department can end up owning configurations and modules that are inseparable from your product. The protective structure is to define deliverables narrowly, carve out pre-existing and background IP, and grant the department a broad licence to the customised solution while you retain ownership of the underlying software.
Can government use my software beyond the licensed scope?
It happens — additional departments, more users than licensed, or continued use after expiry. Enforcement against an organ of state is legally available but commercially and practically hard, so the better protection is drafting: precise scope definitions (named entity, user counts, sites), technical licence controls where feasible, audit and true-up mechanics that convert over-use into payment rather than litigation, and renewal terms that do not depend on the department remembering to act.
What is the GCC?
The general conditions of contract — the standard contractual terms that apply to government procurement contracts. They cover performance, payment, variation, termination, and dispute resolution from the state's perspective, and they are supplemented by special conditions drafted for the specific bid. For a software vendor, the GCC is the baseline you are contracting on: anything your business model needs that the GCC does not provide (licensing structure, IP carve-outs, liability caps) has to be addressed in the special conditions.
How do preference points work?
Bids are scored under the PPPFA preference-point system: the majority of points are awarded for price, with the balance awarded for "specific goals" that each organ of state defines in the tender documents under the current preferential procurement regulations — in practice often linked to B-BBEE status and other transformation objectives. The regime has changed repeatedly, so check the points breakdown in the specific bid documents rather than relying on a general rule. A strong B-BBEE level is frequently the practical difference between competitive and non-competitive bids.
What about selling software to municipalities?
Municipal procurement runs under the Municipal Finance Management Act (MFMA) and each municipality's supply chain management policy — not through SITA. The framework principles are similar (competitive bidding, preference points, standard bid documents), but the processes, thresholds, and contract terms vary by municipality. The same contract battlegrounds apply: state-side terms, IP demands, payment delays, and termination rights all need the same scrutiny.
What does a government tender-pack review cost?
Tender-pack review from R12,500 — a review of the bid documents, GCC and special conditions, and the IP, liability, payment, and licensing positions, with a mark-up of the points to address in clarification questions or special-condition proposals. Larger engagements (full bid support, contract negotiation after award, subcontracting or JV structuring) are quoted on scope.
This guide is general information on South African public procurement as it affects software vendors, not legal advice. Procurement rules — particularly the preferential procurement regulations — change; always check the current bid documents and take advice on your specific tender.