South Africa: A Market Real Users Brought Us To

Recently, we decided to officially add South Africa to SnapLedger's freelancer support.

This decision wasn't made because I first read a market report, or because we calculated how big South Africa's TAM might be.

A more direct reason is Misch — I wrote about him in an earlier diary, “Hire Misch”.

Misch is South African, and one of SnapLedger's earliest contributors and users. Recently, he has been proactively finding more and more South African freelancers to test SnapLedger together, and he keeps bringing back real usage feedback.

This matters a lot to me.

I have always believed that SnapLedger should not advance mechanically, country by country, following a static global expansion map. Wherever real users have already appeared — wherever people are willing to use, test, and tell us what isn't good enough — that is the market we should reach as quickly as possible.

Real feedback is more valuable than market forecasts.

So we started seriously studying how South African freelancers actually work.

At first I thought this was just adding one more country configuration: ZAR, local tax rates, SARS filing cycles, and local invoicing rules. But once I went deeper, I found that South Africa really has its own character.

A typical South African freelancer usually operates as a sole proprietor. Revenue minus reasonable business expenses forms taxable profit, which then enters the personal income tax system — and during the year, they also need to make provisional tax prepayments. From this angle, it's closer to the UK than to France.

But South Africa also has a simplified regime for micro businesses: Turnover Tax.

The problem is, not every freelancer can use it. Professional services in particular — consulting, IT, accounting, management, engineering — can lose Turnover Tax eligibility if this kind of income exceeds a certain share of total receipts.

This means SnapLedger cannot simply let users choose on their own:

“Which tax regime do I want to use?”

The more reasonable approach is to let Snappy first help determine eligibility based on what the user actually does, their income composition, and their books — and only then tell the user what options exist.

This is also one reason I'm increasingly fond of AI-native financial software.

Users shouldn't have to become tax experts before they can start using a finance product.

The software should first understand what is happening, and then tell the user what to do next.

South Africa has another interesting aspect.

Unlike HMRC in the UK, SARS currently does not offer a public filing API that lets an ordinary third-party finance SaaS submit personal income tax returns on behalf of freelancers. So SnapLedger won't simply become a “click a button and file your taxes” interface.

What we plan to build is a more complete SARS Filing + Reconciliation Loop.

Day to day, SnapLedger continuously manages the books.

When a provisional tax deadline arrives, Snappy helps estimate how much should be prepaid, based on income, expenses, and other income sources that have already occurred.

At annual filing time, SnapLedger prepares the business income and expense data needed for the ITR12.

The user still completes the formal filing in SARS eFiling.

Then, once SARS completes its assessment and issues the official ITA34 Tax Assessment, the user can put it back into SnapLedger.

Snappy then compares:

What SnapLedger calculated

against

what SARS finally assessed.

Only when the two sides truly reconcile do we consider that year's tax journey complete.

We even rethought how these government forms should be presented to ordinary freelancers.

IRP5, IRP6, ITR12, ITA34 — if you haven't lived in South Africa for a long time, these names themselves mean almost nothing.

So we don't want SnapLedger to simply tell a user:

“Upload ITA34.”

It should tell them:

SARS Tax Assessment (ITA34) This is the formal tax assessment SARS gives you after the annual filing.

Or:

Employment Income Certificate (IRP5) This is the salary and PAYE certificate issued by your employer — somewhat similar to a W-2 in the US.

Users shouldn't be left not knowing what to do next just because they don't recognize a government form's code.

What excites me even more is that we no longer need to rebuild SnapLedger for South Africa.

SnapLedger's Freelancer Compliance Engine now supports more than 50 countries. The identity, tax calendar, threshold monitoring, declaration, invoice, and country compliance framework we built for France, the UK, Australia, and other markets can all be reused. South Africa is simply the next local module on top of this unified engine.

This also makes our approach to internationalization increasingly clear to me.

We are not building accounting software for fifty different countries.

We are building one unified accounting and compliance engine, and teaching it to understand:

Freelancers in Paris, in London, in Dubai, and in Cape Town or Johannesburg face different regulations — but the problems they really want to solve are remarkably similar:

Tell me what is happening now.

Tell me what I need to do next.

Prepare as much as you can for me.

And finally tell me whether this is truly done.

And this time, South Africa carries another layer of meaning.

It's not a market we picked off a map.

Misch and a group of real South African freelancers brought us here.

I really like this way of expanding.

Where there is real customer feedback, we move closer to the market.

That may also be the most natural path for SnapLedger to enter more countries in the future.