HomeBlogNewsSouth Africa Digital VAT Model: SARS E-Invoicing Plan

South Africa Digital VAT Model: SARS E-Invoicing Plan

South Africa’s Digital VAT Model: SARS Sets Out a Five-Corner E-Invoicing and E-Reporting Framework

On 17 August 2026, the South African Revenue Service (SARS) released a Consultation Paper setting out the future shape of the country’s VAT administration. The proposal, called the Digital VAT Model, rests on structured e-invoicing, a five-corner interoperability framework, near-real-time e-reporting, and VAT returns that SARS pre-fills from transaction data. The stated end-state is full VAT auto-assessment, where compliance “just happens” inside the systems businesses already run. 

That much was expected. The direction has been signalled since the 2023 Discussion Paper, and the Tax Administration Laws Amendment Act that took effect on 1 April 2026 already wrote e-invoicing and voluntary e-reporting definitions into the VAT Act. The value in this paper is not the intent but the architecture: the specific model SARS has chosen, and the choices it has deliberately left open. Written comments are open until 16 October 2026. 

From Post-Audit to Continuous Control 

South Africa currently administers VAT as a self-assessment tax on the invoice-credit method, verified after the fact. SARS sees returns only once they are filed, which leaves it with limited visibility of the underlying transactions and a persistent VAT gap driven by fraud, refund abuse and error. 

The paper proposes to replace that post-audit logic with a Decentralised Continuous Transaction Control and Exchange (DCTCE) model. Structured invoice data would flow between suppliers, buyers, accredited service providers and SARS in near real-time, validated at source rather than reconstructed during an audit. AI and analytics then run across the whole value chain to flag anomalies and concentrate enforcement on high-risk cases. The model stands on three pillars: e-invoicing, an Interoperability Framework, and e-reporting. 

The Five-Corner Model: Decentralised Exchange, Centralised Visibility 

The architecture is a five-corner model, closer in design to the decentralised route France is building than to Italy’s single central clearance platform. Invoices are validated and exchanged through a network of accredited providers rather than funnelled through one government gateway. 

The Five Corners 

  • Corner 1 (Supplier/Issuer): issues a structured e-invoice from its accounting or ERP system, appoints an accredited service provider, and submits the invoice for validation. At this stage it is an “uncleared” e-invoice. 
  • Corner 2 (Supplier’s Access Point): an accredited provider that validates and clears the supplier’s invoice, then transmits it onward. A failed invoice is rejected and returned for correction, which enforces compliance at source and stops invalid tax invoices from circulating. 
  • Corner 3 (Buyer’s Access Point): an accredited provider that receives the cleared invoice, validates it on the buyer’s behalf, delivers it to the buyer, and confirms receipt to Corner 2. 
  • Corner 4 (Buyer/Recipient): receives and automatically processes the invoice, then responds with the VAT treatment of the purchase (fully, partially or not claimed). 
  • Corner 5 (SARS Access Point): the tax authority’s provider, connected to every service provider in the network, receiving VAT data from both sides for risk analysis and return pre-filling. 

Decentralised Validation, Centralised Reporting 

Two points are worth drawing out that the paper states but does not stress. First, this is not a clearance model in the Italian sense. SARS never sits between supplier and buyer, and an invoice is not blocked pending state approval before it reaches the recipient. Validation (“clearance” in the paper’s language) happens at the accredited provider, and the invoice moves on. What SARS operates is decentralised validation plus mandatory reporting, not pre-clearance. 

Second, the “decentralised” label applies to validation, not to the data. Corner 5 is connected to every provider and receives every transaction from both the supplier’s and the buyer’s side. This duplex reporting gives SARS the same invoice from issuer and recipient, which it can match automatically, but it also means that at the reporting layer the model is fully centralised. The decentralisation removes the single point of failure in the exchange, not in SARS’s visibility. 

The Network Authority and Accreditation 

Governing the network is a Network Authority, the body responsible for setting, maintaining and enforcing the technical and legal rules of the exchange. Every Access Point (Corners 2, 3 and 5) must be accredited by it and operate under a service level agreement, and suppliers and buyers choose their own providers from a published accredited list. This is recognisably Peppol-style network logic: the tax authority integrates once, with the network, instead of with every vendor. SARS has not yet selected its preferred Network Authority, and that choice will shape the standards and infrastructure that follow. 

What Qualifies as an e-Invoice 

A valid tax invoice becomes a structured, machine-readable document built on a prescribed data model, not a PDF, a scanned image or an emailed file. It must carry standardised data elements that allow automated validation, matching and VAT reporting, and the obligation extends to e-debit and e-credit notes. 

SARS names three candidate standards but commits to none: EN 16931 CIUS, the UN/CEFACT Cross-Industry Invoice, and Peppol PINT BIS. The detailed requirements will be set later in regulations, and the technical specifications are expected to address the harder VAT cases, including zero rating, deemed supplies and apportionment. Transactions that do not ordinarily require an invoice, such as certain deemed supplies and sector-specific deductions, are flagged for separate treatment during design. 

E-Reporting and the Road to Auto-Assessment 

E-reporting is the mechanism that carries transaction data to SARS. Rather than a return compiled at month-end, VAT data is transmitted through the network just before, during or shortly after each exchange, giving SARS a near-real-time view of activity across the chain. 

The payoff SARS is chasing is automation. Once it holds trusted data from both sides, it can pre-fill VAT returns and, over time, move to auto-assessment of VAT liability. Self-assessment is preserved in principle: the taxpayer still confirms or amends the outcome, so the return becomes a review step rather than a compilation exercise. It is the same direction SARS has already taken with personal income tax auto-assessment, now extended to VAT. 

Where South Africa Sits Globally 

The comparison is instructive for anyone tracking model choice. Latin American systems (Mexico, Brazil, Chile) run mandatory real-time clearance and have posted large results, with Mexico and Chile cited as having roughly halved their VAT gaps. Italy has cleared B2B and B2C invoices through a central platform since 2019. The EU’s ViDA initiative is pushing member states toward harmonised e-invoicing and digital reporting. 

South Africa’s choice is telling: a decentralised, five-corner network rather than a centralised hub, which aligns it with the direction France is taking and with broader Peppol interoperability. Standardising on EN 16931 and Peppol PINT would also leave the door open to cross-border interoperability as ViDA matures. Read against that field, South Africa is picking the architecture that is becoming the default for new adopters, while setting a notably slower pace than most of them. 

The Phased Roadmap 

The detail that will surprise many vendors is the timeline. Nothing is mandatory for years. SARS sets out a five-phase journey: 

  • Phase 1, Preparation (2026/2027, about 12 months): stakeholder consultation and publication of draft VAT regulations. 
  • Phase 2, Solution Development (2027/2028, about 12 months): standards, specifications and operating models defined, regulations promulgated. 
  • Phase 3, Validation (2028/2029, about 6 months): quality-assurance testing with voluntary participants. 
  • Phase 4, Pilot (2029/2030, about 6 months): live, production-like testing with volunteers from priority segments. 
  • Phase 5, Phased Implementation (from 2030, about 36 months): staged mandatory rollout guided by turnover thresholds. 

Phase 5 is sequenced by segment: large taxpayers and B2B first (5a), business-to-government alongside them (5b), then micro, small and medium enterprises (5c), and finally business-to-consumer transactions (5d), where incentives may drive adoption. Large taxpayers are expected to adopt voluntarily before any mandate bites, which puts full rollout somewhere around 2033. For a reform meant to close the VAT gap, that is a long runway, and it is a fair question for the consultation whether the phasing matches the urgency of the problem it is built to solve. 

What SARS Has Not Yet Decided 

For a document this detailed, the open questions are as significant as the commitments, and they are where the consultation can still move the outcome: 

  • The invoice standard. Three candidates are named and none chosen. EN 16931 CIUS, UN/CEFACT CII and Peppol PINT BIS are not interchangeable in practice, and the pick shapes every vendor’s implementation. 
  • The Network Authority. Unselected, with procurement ongoing. This single choice determines the accreditation regime, the technical rules and the network’s governance. 
  • Thresholds, penalties and timing windows. No turnover thresholds, no penalty regime and no defined “near real-time” interval are set. Each is left to later regulation and public comment. 
  • Scope edges. Deemed supplies, sector-specific supplies and non-invoice transactions are explicitly deferred to the design phase. 

For anyone building or operating e-invoicing infrastructure, or advising those who will, this is the window in which those decisions are still contestable. Written submissions are due by 16 October 2026, and the standards, accreditation model and Network Authority selection are all still on the table. 



Leave a Reply

Your email address will not be published. Required fields are marked *