Contractor or employee? The question that decides everything
Almost every other issue on this page — who owns the IP, who handles tax, what happens on termination — turns on how SA law classifies the relationship. And SA law decides that question on substance, not the label. A contract that declares "the Developer is an independent contractor and nothing herein creates employment" does not immunise anyone if the relationship operates like employment in practice.
The courts and the CCMA look at the dominant impression formed by the whole relationship. In plain English, the recurring questions are: control — does the company dictate how, when and where the work is done, or does the developer genuinely manage their own methods and hours? Integration — is the developer woven into the organisation like staff (daily standups, a line manager, performance reviews, a company email address, leave requests)? Economic dependence — does the developer work full-time for this one principal, paid a fixed monthly amount that looks like salary, with no other clients?
Two points surprise foreign companies in particular. First, SA labour law is concerned with where the work is performed — work done in South Africa can attract SA labour protections even where the principal is foreign and the contract chooses foreign law. Second, SA law contains deemed-employment and presumption mechanisms that can treat economically dependent workers as employees in certain circumstances; the detail is fact-specific and worth taking specific advice on before structuring a full-time engagement as contracting.
What misclassification costs
If a "contractor" is in substance an employee, the developer can assert SA labour rights — unfair-dismissal protection, leave and related entitlements — regardless of what the contract says. For a foreign company with an SA presence (a subsidiary, branch or local representative), misclassification can also create PAYE and payroll-compliance exposure for amounts that should have been taxed as remuneration. These consequences are fact-dependent; treat this as the reason to structure deliberately, not as a substitute for specific advice.
The three ways foreign companies engage SA developers
There are three workable structures, and the right one depends on scale, the intensity of the working relationship, and appetite for classification risk.
Direct independent-contractor agreement
The simplest and most common route: the foreign company contracts directly with the SA developer (or the developer's own Pty Ltd). It works well when the relationship is genuinely arms-length — but the three pressure points must be handled deliberately: classification (the working practices, not just the label, must look like contracting), IP (a written, signed assignment that satisfies SA formalities, because a US "work made for hire" clause does not), and money (currency, invoicing cycle, payment rails and who carries bank charges).
Employer-of-record (EOR)
A local EOR employs the developer under a proper SA employment contract and leases the developer's services to the foreign company. The classification risk shifts to the EOR, the developer gets employment-grade stability, and the foreign company avoids creating an SA entity. What to check in the EOR paperwork: the IP chain must be continuous and in writing (developer → EOR → client), data-protection undertakings must flow through, and the contract should be clear on fees, substitution, termination mechanics and who carries which liabilities.
SA subsidiary
For teams at scale, the foreign company incorporates an SA subsidiary and employs the developers directly. This means full SA payroll (PAYE, UIF and related registrations) and SA employment law applying in full — but it is the cleanest structure: works created by employees in the course of their employment vest in the employer under SA copyright law, classification ambiguity disappears, and the company gets a durable local platform for hiring.
A useful rule of thumb: one or two genuinely independent specialists → direct contractor agreements done properly; a handful of full-time, integrated developers → EOR; a committed long-term team → subsidiary.
IP: getting the assignment right under SA law
This is where foreign templates fail most often. US agreements lean on the "work made for hire" doctrine — South African copyright law has no such doctrine, so a clause declaring the deliverables to be works made for hire achieves nothing under SA law. Ownership is decided by SA's own default rules plus whatever valid assignment the parties execute.
Two SA rules do the heavy lifting. First, the formality: under section 22(3) of the Copyright Act, an assignment of copyright is only valid if it is in writing and signed by or on behalf of the assignor. A clickwrap acceptance, an email chain or an unsigned PDF may not satisfy this — the foreign company should insist on a properly signed written assignment, and the developer should know that nothing short of one moves their copyright.
Second, the authorship rule for software: under section 1(1), the author of a computer program is the person who exercised control over the making of the program — confirmed by the Supreme Court of Appeal in Haupt v Brewers Marketing Intelligence. This cuts in both directions. A foreign principal that directs the work closely — detailed specifications, supervision, iterative instruction over what gets built and how — may already be the author and first owner of the code, even without an assignment. An arms-length contractor who builds independently against a brief keeps the copyright, and the client gets nothing more than an implied licence unless a compliant assignment is signed.
The governing-law trap
Choosing California (or English, or Dutch) law to govern the contract does not opt out of SA copyright law. An assignment governed by foreign law must still satisfy SA formalities — written, signed — to transfer the South African copyright in the work. The clean solution is an assignment clause drafted to satisfy section 22(3) on its face, paired with a further-assurances obligation (the developer will sign whatever additional documents are needed to perfect title anywhere) and a moral-rights waiver under section 20, since the author otherwise retains the rights to be named and to object to derogatory treatment of the work.
For the anatomy of a standalone assignment document, see our guide to the IP assignment agreement, and for the broader ownership rules, software development & IP.
Money: getting paid from abroad
The payments layer is more routine than developers fear. Inward foreign payments for services flow through South Africa's normal banking channels — your bank, acting as an authorised dealer, processes the inflow and may ask for the invoice or contract as supporting documentation. Invoicing in USD or EUR is fine; the contract should fix the currency, the invoicing cycle, the payment deadline, and who carries bank and conversion charges, because spread and fees on cross-border payments are real money at developer rates.
Tax is the part to take seriously. An SA tax resident is taxed in South Africa on worldwide income — every dollar the US client pays is taxable here. Because no employer withholds PAYE from contractor invoices, provisional tax registration will generally apply: tax is paid in instalments during the year rather than in one year-end settlement, and missing the cycle attracts penalties and interest.
On the foreign side: a genuinely independent contractor is not subject to the foreign company's payroll withholding — that is one of the structural attractions of the model for both parties. But foreign jurisdictions have their own contractor-compliance, reporting and, in some cases, withholding rules for cross-border service payments, and those are questions of foreign law. Keep this layer general in the contract (each party responsible for its own taxes) and get specific advice — an SA tax adviser for the developer, home-jurisdiction advice for the company.
POPIA and data access
A developer with access to the foreign company's production data — customer records, user accounts, support tickets — is part of that company's processing chain, and the company will (or should) require operator-style undertakings: process only on instructions, maintain defined security measures, report incidents, restrict copying of data to local machines, and return or delete data and credentials on exit.
A common misconception is that POPIA's cross-border provision is what governs here. Section 72 restricts transfers of personal information out of South Africa by SA responsible parties — it is not triggered merely because a South African person receives data from abroad. In the typical inbound scenario, the paperwork is driven by the foreign company's own regime: an EU company will need GDPR Article 28 processor terms (and usually standard contractual clauses) covering its SA contractor; a US company will be working from its state privacy laws and its customer commitments. The SA developer's job is to sign undertakings they can actually honour — and to flag it early if their own setup (shared machines, personal cloud accounts) cannot meet the security commitments being asked of them.
Where the developer also processes South African personal information — local clients alongside the foreign one — POPIA applies to that processing in the ordinary way. For the mechanics of processor paperwork generally, see our guide to data processing agreements.
The contract checklist
Whichever side of the relationship you are on, these are the ten items a remote-developer contract has to get right.
Status clause that matches reality
A clause recording independent-contractor status is only worth something if the working practices support it — autonomy over hours and methods, own equipment where feasible, no integration into employment-style structures.
Scope and deliverables
A defined statement of work or sprint/retainer structure. Open-ended "all duties assigned" language reads like employment.
Written, signed IP assignment
An assignment that satisfies section 22(3) of the Copyright Act — in writing, signed by the assignor — plus a further-assurances clause and a moral-rights waiver (s 20).
Rate, currency and payment terms
Fix the currency (USD/EUR/ZAR), the invoicing cycle, the payment deadline, and who carries bank and conversion charges.
Tax allocation
The contractor is responsible for their own SA tax; the company makes no payroll deductions for a true contractor. Each side should take its own tax advice for its own jurisdiction.
Confidentiality and data undertakings
Security measures, breach notification, limits on copying customer data to local machines, and return or deletion of data and credentials on exit.
Tools, equipment and access
Who provides hardware, licences and environments; how access is provisioned and — critically — revoked when the engagement ends.
Termination and handover
Notice periods workable for both sides, plus handover obligations: code pushed, documentation current, credentials rotated.
Governing law and forum
Choose a governing law and dispute forum that is actually usable by both sides — and understand that SA copyright formalities and SA labour protections for SA-performed work can apply regardless of the choice.
Non-solicitation and restraints
Sized realistically. SA restraint-of-trade law enforces restraints only to the extent they are reasonable — a blanket worldwide bar on working in software is unlikely to survive scrutiny.
Frequently asked
Am I an employee or a contractor if I work full-time for one US company from Cape Town?
The label in your contract does not decide it. SA law looks at the dominant impression of the relationship in substance: who controls how, when and where you work; how integrated you are into the company (standups, a manager, performance reviews, company email); and how economically dependent you are on this one principal. Full-time, single-client, salary-like arrangements are the classic profile that gets reclassified as employment in substance, even where the paper says "independent contractor". If that describes your setup, get specific advice — both the contract and the working practices may need restructuring.
Do SA labour laws protect me against a foreign company?
SA labour law is concerned with where the work is performed, not the nationality of the paymaster — work performed in South Africa can attract SA labour protections even where the principal is foreign and the contract says otherwise. The practical complication is enforcement: pursuing an entity with no SA presence or assets is harder, which is exactly why foreign companies hiring at scale use an employer-of-record or an SA subsidiary. The position depends heavily on the specific facts, so take advice on your particular arrangement.
Who owns the code I write for a foreign client?
Under SA copyright law the author of a computer program is the person who exercised control over the making of the program (s 1(1) of the Copyright Act, confirmed in Haupt v Brewers Marketing Intelligence). That cuts both ways: a foreign principal that closely directs the work — detailed specs, supervision, iterative direction — may already be the author and owner of the code; an arms-length contractor who builds independently keeps the copyright unless it is assigned. And an assignment of SA copyright is only valid if it is in writing and signed by the assignor (s 22(3)) — a clickwrap or an email chain may not be enough.
Should I invoice in dollars or euros?
Yes — invoicing a foreign client in USD or EUR is normal and lawful. Fix the currency in the contract, along with the payment deadline and who carries bank and conversion charges. The funds reach you through your SA bank acting as an authorised dealer; keep your invoices and contract on hand, because the bank may ask for them as supporting documents for the inward payment, and SARS will want the same records.
Do I pay SA tax on income from foreign clients?
If you are SA tax resident, yes — residents are taxed in SA on their worldwide income, including everything a US or EU client pays you. Because no employer is withholding PAYE, provisional tax registration will generally apply, meaning you pay tax in instalments during the year rather than in one settlement. Deductions, structuring through a company, and any cross-border tax questions are fact-specific — engage a tax adviser rather than relying on general guidance.
What is an employer-of-record (EOR) and when does it make sense?
An EOR is a local company that legally employs the developer in SA — proper employment contract, payroll, statutory registrations — and leases the developer's services to the foreign company for a fee. It makes sense when the classification risk of a direct contractor arrangement is too high (full-time, integrated, single-principal work), when the developer wants employment-grade benefits and stability, or when the foreign company wants compliant SA hiring without incorporating locally. Check the EOR contract carefully: the IP assignment chain and the data-protection undertakings must flow all the way through to the client.
Can the contract be governed by foreign law, like California law?
Yes, for the contractual terms — parties are generally free to choose the governing law of their agreement. But the choice has limits: an IP assignment governed by California law must still satisfy SA formalities (written and signed, s 22(3)) to transfer SA copyright, and SA labour protections for work performed in SA can apply regardless of the chosen law. There is also the practical question of forum: a governing-law-plus-courts clause that neither side can realistically litigate under protects nobody.
What does the contract work cost?
The remote-developer contract pack starts from R9,500 — a contractor agreement built for SA law (classification-aware drafting), a written IP assignment satisfying section 22(3) with moral-rights waiver and further assurances, and confidentiality and data-protection undertakings, tailored to whichever side of the relationship you are on. Reviewing and marking up a foreign company's existing template is typically a smaller exercise, quoted once we have seen the document.