Tanzania · TRA EFD / VFD
One record behind every TRA receipt you issue
The fiscal receipt is not the problem. Most Tanzanian shops issue one — through an EFD machine on the counter or a virtual fiscal device on a phone or a PC — because TRA requires it and customers increasingly ask for it.
The problem is that the fiscal device is a second system. It knows what was keyed into it. It does not know what left your shelves, what you paid for it, or which of the four wallets the money arrived in. So the shop ends the day with a receipt total, a stock position and a set of mobile money statements, none of which were produced by the same record.
sell.ke is that single record. What you sold, at what cost, through which rail, in which branch — captured once, so the figure behind the fiscal receipt and the figure behind your margin are the same figure.
What you get
What stops being guesswork
The receipt and the shelf agree
A sale takes the item off the shelf and produces the amount you fiscalise. One action, one number — instead of a cashier keying the sale into the fiscal device and the stock being adjusted later, by someone, approximately.
Four rails, one day-end
M-Pesa, Mixx by Yas, Airtel Money, HaloPesa, card and cash all recorded against the sale that earned them, so the day's takings split by method without anyone opening four statements.
Cost on the way in, margin on the way out
Purchases recorded against suppliers, so the shilling figure you report is attached to a cost you can see — not a turnover figure you are hoping had profit in it.
A trail that survives being checked
Every discount, void and refund carries the name of whoever authorised it and the time they did. A corrected sale is a movement in the record rather than a missing number in the sequence.
What TRA requires, in practice
Tanzania's fiscalisation runs through the Electronic Fiscal Device Management System. A registered trader issues a fiscal receipt for every sale — from a physical EFD machine, or from a virtual fiscal device, which is the same obligation implemented in software. The receipt carries a verification code, and buyers are encouraged to check it, which means the document you issue is a public claim about a sale you must also be able to account for internally.
The enforcement direction has been consistent for years: more receipts, issued closer to the moment of sale, verifiable by the person who paid. For a shop, the practical consequence is that the fiscal receipt becomes the most-checked record in the business — and the least informative one, because it describes money rather than goods.
Nothing in the regulation asks for your stock. Everything about an inspection does. The question that costs businesses money is not whether a receipt was issued, it is whether the receipts, the purchases and what is left on the shelf can be made to tell one story.
- A fiscal receipt for every sale, issued at the counter
- A verification code the buyer can check against TRA's record
- Purchases and sales that reconcile against each other
- Figures that can be defended per branch, not just in total
Why two systems drift apart
An EFD on the counter is keyed by hand. A busy cashier keys the amount, not the item — and once the amount is the only thing recorded, the day's fiscal total can never be tied back to specific goods. Two sales of 10,000 shillings look identical to the device and are completely different to your margin.
Then the money arrives on a rail. Vodacom's M-Pesa, Mixx by Yas, Airtel Money and HaloPesa each produce their own statement, and the shop's job at close is to reconcile a receipt total against four of them plus a cash drawer. That reconciliation is slow enough that most shops stop doing it properly within a fortnight of opening, which is the moment the record stops being evidence of anything.
The drift is cumulative and invisible. Nobody notices in a week. Somebody notices when stock on the shelf is 8 percent below what the purchases and sales imply, and by then there is no way to find which days it happened on.
What sell.ke does about it
The sale is entered once, as items. The cashier scans or taps the product, the quantity comes off that branch's stock, the price comes from the price list rather than from memory, and the amount to fiscalise is the result of that rather than the input to it. The fiscal receipt is then describing a sale the shop can also explain.
Payment method is recorded on the sale, by rail. At close the day splits itself — this much on M-Pesa, this much on Mixx by Yas, this much on Airtel, this much cash in the drawer — so the reconciliation that used to take an hour of comparing statements becomes a comparison against one page of numbers.
Purchases go in against the supplier, so stock arrives with a cost. That is what turns a turnover figure into a margin figure, and it is also what makes a stock variance meaningful: when the shelf disagrees with the record, you can see which product and roughly which week, instead of discovering a shortfall with no shape to it.
- Items, quantities and prices on every sale — the amount is derived, not typed
- Payment split by rail at day-end, across all four wallets plus cash and card
- Supplier purchases and goods-received notes, so stock carries a cost
- Per-branch figures for a business running Dar and upcountry shops
- Offline-first selling, so a dropped connection costs you nothing you need later
Compare
Fiscal device alone vs fiscal device plus a real record
| What you are comparing | EFD / VFD on its own | With sell.ke behind it |
|---|---|---|
| What the record knows | Amounts | Items, quantities, prices, costs |
| Stock position | Counted by hand, occasionally | Moves with every sale |
| Day-end reconciliation | Four statements and a drawer | One page, already split by rail |
| Margin | Estimated at month end | Per product, per branch, live |
| A disputed figure | A till roll | A named, timestamped audit trail |
| Second branch | A second device, separately | Own totals, one catalogue |
What sell.ke does not do here
sell.ke is not a fiscal device and does not transmit to TRA. It does not issue a fiscal receipt, generate a verification code or replace the EFD or VFD you are registered with. Kenya's KRA eTIMS is the only revenue-authority integration the platform ships today.
What it replaces is the hand-keying and the guesswork on your side of that device — the part where nobody can say which goods a day's fiscal total was made of. Keep issuing receipts the way TRA requires; stop being unable to explain them.
Questions
EFD and VFD receipts (Tanzania) — questions
Is sell.ke an approved EFD or VFD?
No. sell.ke is the shop's record of what was sold, bought and held in stock; the fiscal receipt is still issued through the EFD or VFD you are registered with. The two do different jobs — the device satisfies the obligation, the record lets you explain and defend what the device printed.
Does it support M-Pesa, Mixx by Yas, Airtel Money and HaloPesa?
All of them are recorded against the sale at the counter, so your day's takings split by rail without opening four statements. What sell.ke does not do in Tanzania is push a payment prompt to the customer's phone — Kenya's M-Pesa STK push via Daraja is the one mobile-money push the platform ships. The customer pays to your own merchant number as they do now; what changes is that the payment is attached to a specific sale instead of sitting in a statement you reconcile by eye.
My cashier keys totals into the EFD. Why is that a problem?
Because an amount cannot be audited against goods. Two 10,000-shilling sales are identical to the device and may have completely different margins, and when the shelf comes up short there is no way to find which products or which days are missing. Entering the sale as items — which the cashier is doing anyway, physically — makes the fiscal total a consequence of a sale you can describe.
Will it work with intermittent internet?
Yes. The till is offline-first: it keeps taking sales, printing its own receipts and moving stock with no connection, then syncs the backlog when the line returns. The parts that are inherently online stay online — the web shop, anything that needs a live confirmation — but selling never waits for the network.
I run shops in Dar and upcountry. Can I see them separately?
Yes. Branches share one product catalogue but hold their own stock and produce their own sales, payment-method and margin totals. Staff permissions are set per branch, so an upcountry supervisor can run their shop without seeing what Dar is making on each line.
Do I need internet?
Not to keep selling. Offline mode lets the till take sales, print receipts and reserve stock while the connection is down, then syncs everything when it returns. You do need connectivity for the parts that are inherently online: an M-Pesa STK push, an eTIMS submission and the online shop all need a live link.
Will it show me my profit?
Yes, and from a real ledger rather than a sales total. Every sale posts to a double-entry chart of accounts, so you get a trial balance, profit and loss, balance sheet and cash flow — not a CSV to hand your accountant. Margin is visible per product, per branch and per channel, because cost is tracked on the way in through purchase orders and goods-received notes.
Can I stop staff from giving discounts or deleting sales?
Yes. Discounts, voids and refunds sit behind a manager PIN, and every one of them records who authorised it and when. Staff accounts carry role permissions, so a cashier can sell without seeing cost prices, editing products or opening reports. A void that reverses stock is a movement in the audit trail, not a gap in it.
What does it cost?
Plans run from USD 12/month for a single-location till to USD 115/month for unlimited scale, with the online store on your own domain included from USD 23/month. In Kenya the same plans are KES 1,499 to KES 14,999/month, billed in shillings. Every plan starts with a 14-day trial and no card, and there is no per-terminal licence and no commission on your sales. There is no hardware to buy either — sell.ke runs on a phone, tablet or laptop you already own.
The market page this sits under
Go deeper on a feature
Each one goes further than this page does.
Selling at the counter
Split payments, held orders, manager-gated discounts and a drawer count that reconciles.
Stock you can trust
Batch and expiry, serial numbers, reorder levels, stock takes and the formulas behind them.
Reports and real accounting
Double-entry books — trial balance, P&L, balance sheet — not a CSV export to somebody else's software.
Buying, suppliers and approvals
Purchase orders, goods-received notes, supplier bills and the cost figure every margin depends on.
The problems behind this
What this actually fixes in a working shop, written from the problem rather than from the regulation.
The drawer never balances
Cash, M-Pesa, MoMo and a notebook, reconciled by eye at 9pm. Here is the fix.
Not knowing your profit
Takings are not profit. The gap between them is where most small shops quietly fail.
Stock going missing
Why shrinkage is almost never one big theft, and what actually closes the gap.
EFRIS and your POS (Uganda)
Every sale held at the line detail a URA e-invoice needs, before you go to file it.
EBM and your stock (Rwanda)
EBM asks what you bought, sold and still hold. Most shops can only answer one of the three.
Airtel Money at the till
The second rail is a third of your takings and usually a separate book. It should not be.
Try it on your own products
Fourteen days, no card, no hardware to buy. Import your product list or let Amina build it from a photo of your price list, and run it alongside whatever you use now.