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
- Customer
- Platform facilitates
- Independent provider
Platform economic revenue
KES 200
Provider proceeds
KES 800
Visual character: the platform facilitates.
Model B
Principal supplier
- Customer
- Platform sells service
- 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
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
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
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
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
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.


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.
Step 1
Need
Who controls this?
CustomerStep 2
Open platform
Who controls this?
PlatformStep 3
Request service
Who controls this?
CustomerStep 4
Receive price
Who controls this?
PlatformStep 5
Provider allocated
Who controls this?
PlatformStep 6
Service delivered
Who controls this?
ProviderStep 7
Payment
Who controls this?
SharedStep 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
- Customer
- Platform
- Provider
This only tells us where the money travelled.
Follow the control
- Customer
- Pricing
- Matching
- Contract
- Payment
- Fulfilment
- Customer support
- Refunds
- 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.
MU-BEI
Whose money is it?
Client funds vs business revenue
Core challenge: can you prove agency and disbursement?
Read the MU-BEI companion →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
DEFINE THE PARTIES
Customer · Platform · Provider
- 2
DEFINE THE CONTRACTS
Who contracts with whom?
- 3
DEFINE THE SUPPLY
Who supplies what?
- 4
DEFINE THE PRICE
Who sets it?
- 5
DEFINE THE MONEY
Who collects what for whom?
- 6
DEFINE THE INVOICE
Who invoices whom?
- 7
DEFINE THE TAX
VAT / WHT / income consequences
- 8
DEFINE THE LEDGER
Gross or net?
- 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
- Customer: The party who needs the service and whose experience of the brand often shapes how the supply appears commercially.
- Customer Contract: Evidence of who the customer is contracting with — platform, provider, or both.
- Platform Terms: Important evidence of how the business describes and allocates rights, obligations and control.
- Provider Contract: Commission agreements, service standards and settlement rules between platform and provider.
- Price: Who sets or materially determines the customer-facing price — a recurring control indicator in platform disputes.
- Order: The digital record of request, matching and acceptance.
- Fulfilment: Who performs the underlying service and who controls allocation and standards.
- Payment: Where consideration lands — and whether the platform collects in its own name.
- Platform Commission: What the platform economically retains. Important — but not automatically identical to taxable value.
- Provider Settlement: The amount ultimately remitted to the third-party service provider.
- Invoice / RFP: Who demands payment and how that document functions for VAT evidence.
- VAT: How the supply was characterised on the return — commission base or full consideration.
- Ledger: Whether books present gross marketplace activity, net commission, or both.
- GMV: The gross economic activity flowing through the platform. An important commercial metric, but not automatically identical to accounting revenue or taxable value.
- 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
- 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.
| Dimension | Agent / Marketplace | Hybrid | Principal |
|---|---|---|---|
| Customer contract | Provider | Mixed | Platform |
| Pricing | Provider | Shared | Platform |
| Fulfilment | Provider | Shared | Platform-controlled |
| Payment | Facilitated | Controlled | Platform |
| Performance risk | Provider | Shared | Platform |
| Customer support | Provider / shared | Platform-heavy | Platform |
| Platform earnings | Commission | Mixed | Gross less fulfilment cost |
| Tax analysis | Agency-focused | Fact-intensive | Principal-focused |
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.
