Building for Tanzania: Fiscal Receipting and Local Payment Rails

Why "it worked in Kenya" is not a plan

Every year, a handful of Kenyan SMEs, SACCOs, and fintechs look across the border and see an opportunity: a market roughly comparable in size, culturally adjacent, Swahili-speaking, and geographically close enough that a Nairobi-based team can fly in for a week and set things up. Then the team tries to reuse the same point-of-sale system, the same eTIMS-integrated invoicing, and the same M-Pesa STK Push flow, and discovers that almost none of it transfers cleanly. Tanzania is not Kenya with a different currency symbol. It has its own tax authority with its own fiscal device regime, its own mobile money ecosystem with different market dynamics, its own banking regulator, and its own data protection law. If you are building or extending software for a business operating in both countries, you need to treat Tanzania as a genuinely separate compliance and integration surface, not a config flag.

This matters most for three kinds of readers: a Kenyan agency building a system for a client that has opened a branch or subsidiary in Dar es Salaam, Arusha, or Mwanza; a fintech or payments company that wants to route transactions across both markets; and a Kenyan-owned SME or SACCO that is expanding operations across the border and needs its books, receipts, and payments to satisfy Tanzanian regulators, not Kenyan ones. In all three cases, the mistakes are the same: assuming fiscal receipting works the way eTIMS does, assuming M-Pesa Kenya's APIs and M-Pesa Tanzania's APIs are interchangeable because they share a brand name, and underestimating how much local paperwork sits behind what looks like a simple technical integration.

Fiscal receipting: TRA is not KRA, and EFD is not eTIMS

In Kenya, KRA's move to eTIMS has reshaped how businesses issue invoices — software-based, real-time (or near real-time) transmission of invoice data to KRA, with various onboarding routes depending on business size and system maturity. Tanzania's revenue authority, the Tanzania Revenue Authority (TRA), has run its own fiscal receipting regime for considerably longer, built around Electronic Fiscal Devices (EFDs) and their software equivalents, sometimes referred to as Virtual Fiscal Devices depending on the category of business and how the device is implemented. The underlying goal is similar to eTIMS — every taxable sale needs to be recorded on a system TRA can see into, with a fiscal receipt issued to the customer — but the technical mechanics, the certification process for devices and software, the vendor ecosystem, and the specific data fields required are all different from what you built for KRA compliance. If your business or your client's business is required to fiscalize sales in Tanzania, do not assume your eTIMS integration can be adapted with a URL change. You will need to work with a TRA-approved EFD supplier or software provider operating in Tanzania, understand which category your business falls into (retail, VAT-registered, import/export, and so on carry different obligations), and confirm current requirements directly with TRA or a licensed local tax agent before you write a line of integration code. The specific thresholds, penalty regimes, and technical specifications change over time and vary by business type — treat anything you read online, including this article, as a starting point for questions to TRA, not as a final answer.

A practical consequence for developers: build your invoicing and point-of-sale logic so that the "fiscal receipting" step is a pluggable module, not something hard-wired into your core sales flow. If you've built for the Kenyan market with eTIMS in mind, you likely already have a layer that takes a completed sale and pushes it to a tax authority endpoint, then stores the returned receipt number or QR code. Keep that abstraction. For Tanzania, that same abstraction should call a different provider, expect different response fields, and store different reference data — but the rest of your sales, inventory, and reporting logic can remain largely untouched. Businesses that hard-code KRA-specific field names and response formats into their core order objects end up rebuilding the whole system for Tanzania instead of swapping one module.

Payment rails: M-Pesa is not one thing across the border

This is where Kenyan teams get tripped up most often. M-Pesa in Kenya is operated by Safaricom, and most Kenyan developers have built against Safaricom's Daraja APIs — STK Push, C2B, B2C, and so on — enough times that it feels like a solved problem. M-Pesa in Tanzania is operated by Vodacom Tanzania, a separate telco with its own regulatory relationship with the Bank of Tanzania (BoT), its own API platform, its own merchant onboarding process, and its own commercial terms. Sharing a brand name does not mean sharing infrastructure, credentials, or even feature parity. You cannot use Kenyan Safaricom API credentials to move money on Tanzanian M-Pesa, and the integration you write for Daraja will need to be substantially rebuilt, not just repointed, for Vodacom Tanzania's platform.

Beyond M-Pesa, Tanzania's mobile money market includes other significant players — Airtel Money, and the operator historically known as Tigo Pesa, which has gone through rebranding in recent years. Because telco branding and market share shift over time, don't hard-code assumptions about which operator dominates a given region or customer segment; confirm the current landscape with a local payments aggregator or the Bank of Tanzania before committing engineering time to a specific rail. What is durable and worth building for is interoperability: Tanzania has invested in a national instant payment infrastructure intended to let money move between different mobile wallets and bank accounts more seamlessly, in a similar spirit to how Kenya's Pesalink connects banks. If your system needs to accept payments from any Tanzanian customer regardless of which wallet they use, look at working through a licensed local payment aggregator or switch that already holds the necessary agreements with the mobile network operators and banks, rather than trying to integrate with each operator's API directly. This is both a technical shortcut and a compliance necessity — the Bank of Tanzania licenses and supervises payment service providers, and running money movement infrastructure without the right local registration is not something you can quietly route around from Nairobi.

Entity, licensing, and the question you must ask before writing code

Before any integration work starts, settle the legal and licensing question: does the business have a registered presence in Tanzania, and does it hold whatever licenses are required for the activity it intends to carry out — retail trading, financial services, telemedicine, education services, and so on each carry different requirements. A Kenyan-registered company generally cannot simply operate and collect payments in Tanzania using its Kenyan registration and Kenyan bank accounts; cross-border operation typically requires local incorporation or a registered branch, tax registration with TRA, and often sector-specific licensing. This is not a technical detail you can solve with an API key — it is a legal foundation that needs to be in place, usually with the help of a Tanzanian lawyer or corporate services firm, before your engineering team builds anything that touches real customer money or real fiscal receipts. Skipping this step to "launch fast" is one of the more expensive mistakes a Kenyan business can make when crossing the border, because unwinding an improperly structured operation is far costlier than the delay of doing it properly upfront.

Data protection, connectivity, and forex — the quieter constraints

Tanzania has its own personal data protection framework and its own data protection authority, distinct from Kenya's Office of the Data Protection Commissioner. If your system collects customer data — names, phone numbers, national ID numbers, health or financial records — from Tanzanian users, you need to understand Tanzania's rules on data handling, cross-border data transfer, and consent separately from your Kenyan compliance posture. Do not assume that being compliant with Kenya's Data Protection Act automatically satisfies Tanzanian requirements; confirm directly with the relevant Tanzanian authority or a local counsel.

On the operational side, the same constraints that shape software in Kenya apply in Tanzania, often more acutely outside Dar es Salaam: variable connectivity, power interruptions, and a mobile-first user base with limited tolerance for data-heavy apps. Build offline-tolerant sync into your point-of-sale and fiscal receipting flows — queue transactions locally and reconcile with TRA and payment providers when connectivity returns, the same discipline you'd apply for a shop in a low-connectivity part of Kenya. And budget deliberately for forex exposure: if any part of your stack is priced in US dollars — cloud hosting, third-party APIs, licensed software — that cost is now exposed to both KES and TZS movement against the dollar, plus the cost of moving money between the two shillings themselves. For a small team or a lean SACCO project, that double forex exposure can quietly erode a budget that looked fine on the day it was approved.

The practical starting point

If you're serious about building for Tanzania, start with three conversations before you start with code: a Tanzanian tax agent or the TRA directly, about fiscal receipting obligations for your specific business category; a licensed local payment aggregator, about which payment rails actually make sense for your customer base and what integration route is realistic; and a Tanzanian corporate lawyer, about what entity structure and licensing you need before you touch a shilling of customer money. Everything else — the APIs, the offline sync, the receipt formatting — is engineering work your team already knows how to do. The part that trips up Kenyan businesses is treating a neighboring, culturally familiar market as functionally identical to home. It isn't, and the businesses that succeed across the border are the ones that budgeted time and money to learn the difference before they launched, not after.