← All insights
ClariFi
Plan. Measure. Perform.

From Data to Decisions

PLATFORM ECONOMY • TAX INTELLIGENCE • KENYA
By Kinako, KAN Consultants18 min read

When KRA Calls Your Platform's GMV Your Sale

The Sendy judgment, the difference between commission and gross transaction value, and the question every Kenyan digital platform should ask: who really made the sale?

Who really made the sale?

Customer

KES 1,000

into the platform

KES 200

Platform revenue

KES 800

Provider proceeds

Tax characterisation

KES 1,000

Underlying supply?

Is the platform an intermediary—or the supplier?

Illustrative numbers used to explain the business-model issue; they are not Sendy's actual transaction values.

Conceptual Nairobi dusk transaction network: delivery routes and luminous digital payment lines converging into a floating platform layer above the city

2,000+businesses

Kenyan MSMEs use ClariFi to plan, measure, and perform.

  • Platform Economy
  • Tax Intelligence
  • Kenya

The KES 1,000 thought experiment

A Nairobi business needs a delivery. It opens an app. The app finds a transporter, presents a price, facilitates the order, shapes parts of the customer journey, receives or facilitates payment, and records the transaction.

The customer pays KES 1,000. The platform ultimately retains KES 200. The transporter receives KES 800.

KES 1,000

Platform commission / margin

KES 200

Service provider / transporter share

KES 800

How much did the platform sell?

Business model view

Revenue

KES 200

Tax characterisation view

Underlying supply

KES 1,000

Illustrative numbers used to explain the business-model issue; they are not Sendy's actual transaction values.

The same KES 1,000 — two business models

Same money flow. Very different tax architecture.

Model A

Marketplace / Agent

  1. Customer
  2. Platform facilitates
  3. Independent provider

Platform economic revenue

KES 200

Provider proceeds

KES 800

Visual character: the platform facilitates.

Model B

Principal supplier

  1. Customer
  2. Platform sells service
  3. Platform fulfils through transporter

Customer-facing supply

KES 1,000

Provider cost / settlement

KES 800

Visual character: the platform supplies.

Same money flow.

Very different tax architecture.

The actual tax result depends on law and facts; this illustration is a conceptual model, not a universal tax rule.

Meet Sendy — and the path to the High Court

The platform label is not the business model. The judgment asked what the commercial architecture actually did.

Primary sources: Tribunal judgment (Kenya Law) · High Court judgment (SheriaHub).

  1. 1

    CHAPTER 1

    Sendy builds a marketplace

    On the High Court's own description, Sendy operated as a digital marketplace connecting independent third-party transporters with customers who needed goods moved. Sendy argued it was a technology company whose taxable supply was platform access — and that it had accounted for VAT on its commission.

  2. 2

    CHAPTER 2

    KRA looks through the app

    The Commissioner's audit did not stop at the marketplace label. Banking analysis, Requests for Payment (RFPs), and the operational reality of how jobs were priced, dispatched and collected became the centre of the dispute. The confirmed VAT assessment stood at Kshs 82,248,150.74; corporation tax was vacated.

  3. 3

    CHAPTER 3

    The Tax Appeals Tribunal

    On 5 April 2024, the Tribunal allowed Sendy's appeal. It characterised Sendy as a platform provider, found that third-party transporters made the transport supply, and set aside the objection decision — treating Sendy's VAT base as commission, not gross customer receipts.

  4. 4

    CHAPTER 4

    The High Court revisits the model

    On appeal, the High Court held that the characterisation of who makes the supply under section 5(1) of the VAT Act raised questions of law. Looking at economic reality — price, algorithmic dispatch, RFPs in Sendy's name, and collection of the full consideration into Sendy's accounts — the Court set aside the Tribunal and upheld the VAT assessment.

  5. 5

    CHAPTER 5

    Platform or principal?

    The Court concluded that Sendy acted as principal for VAT purposes: deemed to receive the transport service from the transporter and supply it to the customer. VAT liability attached to the full customer consideration — not merely the commission. A prior private ruling could not override that statutory interpretation.

Transparent digital interchange showing customers, transporters, payments, invoices and data flowing through a platform centre labelled intermediary or principal
A digital interchange: customers, providers, money, invoices and data flowing through one commercial architecture.
Abstract visualisation of platform control nodes — pricing, matching, payment and fulfilment — leaving a tax footprint across a commercial architecture
Control leaves a tax footprint — across pricing, matching, payment and fulfilment.

What the customer experiences

Forget what the incorporation documents call the company. Forget what the pitch deck calls the company. Look at what the customer experiences.

  1. Step 1

    Need

    Who controls this?

    Customer
  2. Step 2

    Open platform

    Who controls this?

    Platform
  3. Step 3

    Request service

    Who controls this?

    Customer
  4. Step 4

    Receive price

    Who controls this?

    Platform
  5. Step 5

    Provider allocated

    Who controls this?

    Platform
  6. Step 6

    Service delivered

    Who controls this?

    Provider
  7. Step 7

    Payment

    Who controls this?

    Shared
  8. Step 8

    Complaint / refund

    Who controls this?

    Shared

The Platform Control Map

A commercial architecture diagnostic — not a statutory checklist.

Centre

Who is the supplier?

A commercial architecture diagnostic based on the broader principal-versus-agent question — not a statutory checklist.

The Sendy Control Meter

The more control a platform assumes, the harder it may become to argue that it is merely passive infrastructure. That is an observation about commercial reality — not an automatic legal formula.

Pure marketplace

Full principal

Marketplace simply introduces parties ↔ Platform controls most elements of fulfilment

Conceptual position for a high-control logistics platform — illustrative, not a case score

  • Listing
  • Discovery
  • Matching
  • Pricing
  • Contracting
  • Payment
  • Allocation
  • Fulfilment control
  • Refunds
  • Guarantees
  • Customer relationship

GMV ≠ Revenue ≠ Tax base

GMV is a business metric. Taxable value is a legal conclusion.

GMV

KES 100M

Total transactions moving through the ecosystem.

Accounting revenue

KES 20M

What the platform recognises economically in this illustration.

Possible taxable supply

?

Depends on the legal characterisation of the platform's role.

The P&L trap

Your P&L can answer “what did we earn?” It may not fully answer “what did we supply?”

What the CFO sees

Revenue

= Commission

Accounting presentation answers an economic question: what did the business earn? Accounting standards are not irrelevant — they are answering a different question.

What tax analysis asks

Supply

= ?

Tax characterisation looks at commercial substance: contracts, control, invoicing and who made the taxable supply. Those answers need to be considered together.

Your P&L knows what you earned. Does it know what you supplied?

Follow the control, not just the cash

Follow the money

  1. Customer
  2. Platform
  3. Provider

This only tells us where the money travelled.

Follow the control

  1. Customer
  2. Pricing
  3. Matching
  4. Contract
  5. Payment
  6. Fulfilment
  7. Customer support
  8. Refunds
  9. Platform rules

This helps us ask: who actually orchestrated the supply?

The Transaction Stack

Tax treatment is not something pasted onto a platform after launch. It grows out of the architecture underneath it.

CUSTOMER EXPERIENCE LAYER

  • App
  • Brand
  • Checkout
  • Support

COMMERCIAL LAYER

  • Price
  • Contract
  • Commission
  • Refunds

OPERATING LAYER

  • Matching
  • Provider allocation
  • Service standards
  • Performance

MONEY LAYER

  • Customer payment
  • Platform share
  • Provider settlement

TAX LAYER

  • Invoice
  • VAT
  • Revenue
  • Evidence

Business model

Code is commercial architecture.

Business-model self-assessment

Take the Sendy Test

If your business operates a platform, marketplace or aggregator, answer these questions before your next tax audit. Check items where the platform (not an independent provider) materially controls the point.

🟢 0/15 control indicators checked

Mostly facilitation characteristics

Marketplace indicators

  • Mostly unchecked → Marketplace indicators
  • Mixed checks → Principal–agent ambiguity
  • Many checked → Principal-characterisation risk deserves review

This is a business-model self-assessment, not a legal conclusion or tax opinion.

Two cases. One big question.

Money is only half the story. The other half is the business model.

SENDY

Whose sale is it?

Platform GMV vs platform commission

Core challenge: are you facilitating the supply—or making it?

MU-BEI

  • Money ownership
  • ↓ Agency
  • ↓ Documentation

Hub

Principal–agent architecture

SENDY

  • ↑ Control
  • ↑ Service delivery
  • Supply ownership

Whose money? Whose sale? Can you prove it?

Beyond Sendy — Kenya's digital economy

The judgment does not mean every marketplace faces identical VAT treatment. It demonstrates why each should examine its own transaction architecture.

Agent? Marketplace? Principal?

  • Logistics platforms
  • Delivery apps
  • E-commerce marketplaces
  • Accommodation marketplaces
  • Mobility platforms
  • Freelance marketplaces
  • Booking platforms
  • Procurement marketplaces
  • Payment aggregators
  • Professional-service platforms
  • Social commerce
  • Group-buying platforms
  • Fintech ecosystems
  • Embedded finance
  • Software marketplaces

A boardroom scenario

Founder

“Our GMV is KES 1 billion and our revenue is KES 150 million.”

Tax director

“Good. Now show me why the other KES 850 millionis not consideration for supplies made by us.”

Before you code the marketplace, code the commercial model

  1. 1

    DEFINE THE PARTIES

    Customer · Platform · Provider

  2. 2

    DEFINE THE CONTRACTS

    Who contracts with whom?

  3. 3

    DEFINE THE SUPPLY

    Who supplies what?

  4. 4

    DEFINE THE PRICE

    Who sets it?

  5. 5

    DEFINE THE MONEY

    Who collects what for whom?

  6. 6

    DEFINE THE INVOICE

    Who invoices whom?

  7. 7

    DEFINE THE TAX

    VAT / WHT / income consequences

  8. 8

    DEFINE THE LEDGER

    Gross or net?

  9. 9

    DEFINE THE DATA

    Can the position be proved?

Then build the technology.

The Platform Evidence Graph

Central node: the transaction. Tap or hover to see what each layer proves — and what it does not.

Transaction

Text version of the platform evidence chain
  1. Customer: The party who needs the service and whose experience of the brand often shapes how the supply appears commercially.
  2. Customer Contract: Evidence of who the customer is contracting with — platform, provider, or both.
  3. Platform Terms: Important evidence of how the business describes and allocates rights, obligations and control.
  4. Provider Contract: Commission agreements, service standards and settlement rules between platform and provider.
  5. Price: Who sets or materially determines the customer-facing price — a recurring control indicator in platform disputes.
  6. Order: The digital record of request, matching and acceptance.
  7. Fulfilment: Who performs the underlying service and who controls allocation and standards.
  8. Payment: Where consideration lands — and whether the platform collects in its own name.
  9. Platform Commission: What the platform economically retains. Important — but not automatically identical to taxable value.
  10. Provider Settlement: The amount ultimately remitted to the third-party service provider.
  11. Invoice / RFP: Who demands payment and how that document functions for VAT evidence.
  12. VAT: How the supply was characterised on the return — commission base or full consideration.
  13. Ledger: Whether books present gross marketplace activity, net commission, or both.
  14. GMV: The gross economic activity flowing through the platform. An important commercial metric, but not automatically identical to accounting revenue or taxable value.
  15. Audit Evidence: What survives when the tax authority reconstructs the transaction from contracts, bankings, RFPs and operational control.

Every transaction has an identity

Most accounting systems know date, amount, account, customer and supplier. Digital platforms increasingly also need to know: whose sale, whose money, whose customer, whose obligation, whose risk, whose tax.

Call this: Transaction Identity.

ClariFi-style data card

Transaction: #DLV-48291

Control risk: Medium
GMV
KES 1,000
Platform revenue
KES 200
Provider settlement
KES 800
Commercial role
Marketplace / Principal / Hybrid
Contract evidence
VAT treatment
Reconciliation

Conceptual illustration — not necessarily a current ClariFi feature.

The bigger question is transaction intelligence — systems capable of explaining how much money moved, what economic activity generated it, who earned it, who supplied the underlying service, what portion belongs to a third party, which contract governs it, how it was recorded, how it was taxed, and whether all systems tell the same story.

This is the kind of transaction intelligence modern platforms increasingly require.

Four numbers every platform CFO should know

01

GMV

Everything flowing through the platform.

02

NET REVENUE

What the business economically recognises.

03

PROVIDER SETTLEMENTS

What is payable to ecosystem participants.

04

TAXABLE VALUE

What tax law treats as consideration for the relevant taxable supply.

Principal–agent–platform matrix

Conceptual business-model framework — not a statutory test.

  • Customer contract

    Agent / Marketplace
    Provider
    Hybrid
    Mixed
    Principal
    Platform
  • Pricing

    Agent / Marketplace
    Provider
    Hybrid
    Shared
    Principal
    Platform
  • Fulfilment

    Agent / Marketplace
    Provider
    Hybrid
    Shared
    Principal
    Platform-controlled
  • Payment

    Agent / Marketplace
    Facilitated
    Hybrid
    Controlled
    Principal
    Platform
  • Performance risk

    Agent / Marketplace
    Provider
    Hybrid
    Shared
    Principal
    Platform
  • Customer support

    Agent / Marketplace
    Provider / shared
    Hybrid
    Platform-heavy
    Principal
    Platform
  • Platform earnings

    Agent / Marketplace
    Commission
    Hybrid
    Mixed
    Principal
    Gross less fulfilment cost
  • Tax analysis

    Agent / Marketplace
    Agency-focused
    Hybrid
    Fact-intensive
    Principal
    Principal-focused

Closing argument

A founder may think: “We run a technology platform.”

An accountant may think: “We recognise only the commission as revenue.”

A product manager may think: “We merely match supply with demand.”

A customer may think: “I bought the service from the app.”

A service provider may think: “I work through the platform.”

And KRA may ask: “Who actually made the taxable supply?”

The judgment demonstrates why merely calling a business a “platform” does not end the tax inquiry. In Commissioner of Domestic Taxes v Sendy Limited (Income Tax Appeal E137 of 2024) [2025] KEHC 14814 (KLR), the High Court upheld a VAT assessment of Kshs 82,248,150.74 after finding decisive control over pricing, dispatch, billing and payment collection. Sources: Tribunal judgment (Kenya Law); High Court judgment (SheriaHub).

WHOSE SALE IS IT — AND CAN YOU PROVE IT?

Your platform is a commercial architecture: contracts, pricing, payment flows, fulfilment and control. If those layers do not tell one coherent tax story, book a tax advisory consultation before your next audit conversation.

This article is provided for general business and tax education only and does not constitute legal, accounting or tax advice. Platform arrangements differ materially, and businesses should obtain professional advice based on their contracts, transaction flows and specific circumstances.