SARS, VAT & Rand Operations: What Your Business System Should Handle
A VAT vendor is judged on the evidence behind the return rather than on the return itself — which is why "SARS-compliant software" is a claim about the wrong thing. What to hold, where it should live, and the reconstruction test that separates a records system from a filing story.
The most misleading sentence in South African business software is "SARS compliant". It is misleading not because it is a lie but because it answers a question nobody needed answered. Compliance is a property of what you submit and what you can substantiate. It is not a feature that can be installed, and no product can hold it on your behalf.
What software can do is decide whether, on the day somebody asks, the evidence behind a figure exists in a form that survives inspection — or whether it has to be assembled from memory, email and a shared drive by the one person who was there.
That distinction is the whole subject of this post. Nothing here is tax advice; confirm every treatment, threshold and rule with SARS or your own tax practitioner.
The return is the easy part
Filing a VAT return is arithmetic over a period. Any competent bookkeeper with a clean trial balance can produce one, and most South African finance packages will help. The difficulty has never been the submission.
The difficulty arrives later, when a figure on that return is queried and you are asked to stand behind it. At that point the question is not "what did you claim" but "show me". And the answer is decided by choices made months earlier, at the moment each transaction was captured, by people who were not thinking about SARS at all.
Nobody fails a verification because they could not do the sum. They fail because the paper behind the sum went somewhere nobody can find.
The evidence chain, and where it usually breaks
Behind every input tax figure sits a chain: something was ordered, approved, delivered, invoiced, paid and recorded. In a healthy system each link points at the next and all of them hang off the same transaction. In most businesses the chain is intact but distributed — the order is in the system, the approval is in somebody's inbox, the delivery note is in a lever-arch file in the warehouse and the invoice is in an email thread.
Distributed is not the same as lost, and for a small operation it can hold together for years. It fails at exactly the wrong moment: when the person who knew where things were has left, when the query covers a period two financial years back, or when there are four hundred transactions to substantiate rather than four.
The reconstruction test
There is a single test that tells you more about a system than any compliance claim, and you can run it in a demo or on the software you already own. Pick a transaction at random from six months ago. Then, from the record alone, produce the order, who approved it, what was actually delivered, the supplier's invoice, and the tax treatment applied — without phoning anybody and without opening a shared drive.
How long that takes is your real compliance posture. Under a minute means the chain is attached. Twenty minutes means it is reconstructable by someone who knows the business. If the honest answer is "we would have to ask Thabo", then Thabo is your compliance system, and Thabo is going to take annual leave.
Four questions that separate records from filing stories
Does the system submit our VAT return to SARS?
The answer you will get
Usually a redirect — "it produces everything your accountant needs", or "it exports in the right format".
What to do with it
That is a perfectly good answer, and it is a no. Accept it and move on to the questions that matter. Be wary of any vendor who lets you leave believing otherwise.
Is input tax captured at entry, or worked out afterwards?
The answer you will get
A demonstration of a purchase screen with a tax field on it.
What to do with it
Watch whether net, tax and gross are separated on the line at the point of capture, and whether the treatment is a property of the transaction or a setting somebody applies later in bulk. Later-in-bulk is how apportionment errors are born.
Where does the supplier invoice live?
The answer you will get
A file upload, an attachment tab, or a document management module.
What to do with it
Fine — but ask to retrieve one from a transaction a year old, and ask what happens when a document is replaced. An attachment you can silently overwrite with no history is a liability rather than evidence.
Can we correct a past period?
The answer you will get
Yes, transactions can be edited or reversed.
What to do with it
The right answer involves a reversing entry with a reason and a trail, not a quiet edit. If a figure in a filed period can be changed with no record of the change, your evidence chain has a hole in it that nobody will notice until it matters.
Imports, the rand and the input side
For importers there is a second failure that is not a compliance failure at all but shows up in the same records. Goods bought in foreign currency get costed at a rate somebody assumed, and the true cost of the consignment — the rate actually paid, plus duty, freight, clearing and handling — is never folded into the item.
The same consignment, two ways of recording it
Illustrative figures indexed to 100 — not a quotation, not tax advice, and deliberately not tied to any rate. The point is the shape: price this off 100 with a 20% target and you believe you made 20. You made a little under 1. The tax treatment of each component is a separate question for your practitioner; the costing error is yours to fix regardless of how the tax lands.
This is ordinary landed cost applied per consignment. What makes it hard by hand is that each component arrives at a different time from a different party, and by the time the last one lands the goods have been priced and half of them sold.
What we do and do not do
Stated plainly, because this is the section where vendors in this category are least plain.
What AWRA OpsHub does today
- The rand and a South African VAT rate ship as built-in presets in our tax and currency configuration.
- Net, tax and gross separated line by line on purchases as well as sales, at the point of capture rather than afterwards.
- Additional tax lines you can configure with their own rates, effective dates and inclusive or exclusive treatment.
- Source documents attached to the transaction — quote, approval, delivery note, invoice — retrievable from the record itself.
- Foreign-currency purchases recorded at the rate actually paid, with landed cost folded into true unit cost.
- A trail on corrections, so an adjustment to a past period is visible as an adjustment.
What it does not do
- No SARS eFiling integration. Nothing is submitted to SARS on your behalf, in any form.
- We do not file returns and we produce no statutory return output.
- We do not interpret South African VAT rules — zero-rating, exemption, apportionment and adjustments are your practitioner's work, not a setting we maintain.
- One maintained VAT preset ships, not a maintained rate history. Additional lines are configurable by you and yours to keep current.
- No e-invoicing. Our fiscal e-invoicing integration is Kenya's eTIMS and it is Kenya-only.
- Not a customs or clearing system — we record what an import cost, not what it required.
If you take one thing from this post, take the difference between a records claim and a submission claim. A vendor saying "we handle your VAT" may mean either, and the two are separated by a very large amount of your own accountability. Ask which one they mean, in writing, and confirm all treatment with SARS or your tax practitioner.
Everything in that right-hand column can be built for you
The list above is what ships in the standard product today, not the limit of what AWRA OpsHub can do in South Africa. Kenya's eTIMS integration exists because Kenyan clients needed it and commissioned it — it did not arrive on its own. The same door is open here. If SARS submission output, a maintained rate history, a bank feed or an EMP201-shaped return matters to your operation, tell us and we will scope it as a build — with a written spec, a timeline and a price — before you commit to anything.
SARS output and e-invoicing
VAT201-shaped return output from live records, a maintained rate history rather than one preset, and e-invoicing against any prescribed interface — built the way eTIMS was, with retries, a failure queue and a reconciliation report.
Banks, EFT and card acquirers
Bank statement feeds, EFT and debit-order files, and card acquirer settlement reports pulled into the Payments Register so receipts match invoices without anyone re-keying a statement.
Payroll and statutory submissions
EMP201 and EMP501 schedules, UIF declarations and COIDA returns produced in the layout your filing body expects, generated from live payroll records instead of rebuilt each month.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it belongs.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedWhat good practice looks like, whatever you buy
- Capture tax at the line, at entry. Not as a period-end classification exercise. The person keying the transaction knows more about it than anyone will in March.
- Attach the document to the transaction, not to a folder. Folders depend on naming discipline, which depends on the person, who will eventually leave.
- Reverse, do not overwrite. A correction with a reason and a date is evidence. A silent edit is a gap.
- Reconcile on a rhythm, not at filing time. Monthly beats quarterly, and quarterly beats discovering it in an audit.
- Keep the practitioner boundary explicit. Write down who owns treatment decisions and who owns capture. Most VAT trouble lives in the gap where each assumed the other had it.
- Test the chain twice a year. Run the reconstruction test on a random transaction. It costs ten minutes and tells you the truth.
Our take
Stop shopping for compliance and start shopping for substantiation. The system that wins is the one where an arbitrary transaction from last year can produce its own order, approval, delivery note and invoice in under a minute — because that is the only property that behaves the same whether you are being audited, refinanced, sold or simply asked a hard question on a Tuesday.
Run the reconstruction test on us
Bring a real transaction shape from your business and we will show you the chain end to end — order, approval, delivery, invoice, tax treatment — from the record itself.
Explore AWRA for South AfricaFrequently asked questions
Does AWRA OpsHub submit VAT returns to SARS?
No. There is no SARS eFiling integration and nothing is submitted on your behalf. Our only fiscal e-invoicing integration is Kenya's eTIMS and it is Kenya-only. AWRA holds the operational and sales records your VAT position is built from — with net, tax and gross separated on every line and source documents attached to the transaction — and your accountant or tax practitioner files from those records. If direct submission is essential to your workflow, make it a written requirement before committing, with us or any vendor.
Does it handle South African VAT rates?
The rand and a South African VAT rate ship as built-in presets, and every sales and purchase line separates net, tax and gross at the point of capture. We ship one maintained VAT preset rather than a maintained rate history or a rules engine. Additional tax lines can be configured with their own rates, effective dates and inclusive or exclusive treatment, but those definitions are yours to specify and keep current. Have your practitioner define them and confirm current rates and treatment with SARS.
What about zero-rating, exemption and apportionment?
Those are treatment decisions and they stay with your tax practitioner — we do not interpret them and we do not maintain rules that apply them for you. What the system contributes is that the underlying transactions are captured with their tax components separated at entry, with documents attached, so your practitioner is applying treatment to clean records rather than reconstructing them first. For any organization with mixed supplies this distinction matters more than any software feature.
How does it handle imports when the rand moves?
Foreign-currency purchases record the exchange rate actually applied to that transaction, and landed cost folds duty, freight, clearing, handling and inland transport into the true unit cost of the goods received. Margin is then measured against what the consignment genuinely cost rather than against a rate assumed at order time. The tax treatment of each component is a separate question for your practitioner; the costing discipline is worth having either way.
Can we correct a transaction in a period we have already filed?
Corrections are made as visible adjustments with a reason and a trail rather than as silent edits to history. That is the behaviour you want — an adjustment you can explain is evidence, whereas a figure that quietly changed is a hole in your substantiation. How the correction should then be reflected in your filing is a question for your tax practitioner.
Is the system POPIA compliant?
No product can make that claim honestly, because POPIA obligations attach to you as the responsible party rather than to software. What we will do is tell you in writing where your data is hosted, who can access it, how long backups are retained and what you receive if you leave, so your own advisers can assess it. Treat any vendor who answers that question with a single unqualified word as having answered a different one.
