Bank of Tanzania Reference Rate API for Accounting, Invoicing & Compliance

If your business invoices, imports, or reports in a currency other than the TZS, sooner or later someone will ask which rate you used — and “the one on the internet that day” is not an answer that survives an audit. For that, you want the official number: Bank of Tanzania’s published indicative rates.

What are the Bank of Tanzania indicative rates?

The Bank of Tanzania publishes daily indicative shilling rates — mean, buying and selling — for about 40 currencies, including the East African Community pairs. It is the official reference for Tanzanian banks, customs valuation and business accounting.

It is published once every business day, currently covering 38 currencies, and the published record runs back to 2010. Crucially it is a published figure, not a live market price — it does not move after it is set, which is exactly the property an accountant or an auditor needs.

Tanzanian customs valuation and accounting reference the BoT indicative mean rate for shilling conversion.

Why finance teams need the official rate

Book closing and month end

Foreign-currency balances have to be translated at a defensible rate on a specific date. Using a live market rate means the number changes depending on what minute you pulled it, and two people closing the same month can produce two different sets of books. The central bank’s published rate for that date is fixed and reproducible forever.

FX gain and loss

Revaluing receivables and payables needs the rate at invoice date and the rate at settlement date. Both have to come from the same series, or the gain and loss you report is partly an artefact of switching data sources mid-stream.

Audits and compliance

An auditor does not want a screenshot. They want a rate that traces back to a named publisher and a publication date they can independently check against Bank of Tanzania’s own release. That is the entire reason official rates exist.

Management reporting

Group reporting across entities only consolidates cleanly when every entity converts at the same published rate for the same date. Left to their own devices, subsidiaries will each pick a different source.

The problem with collecting the rate by hand

Bank of Tanzania publishes the data — but publishing and being easy to consume are different things. In practice teams end up copying figures off the bank’s rates page into a spreadsheet every morning, which creates four familiar problems:

• It is manual, so it gets skipped. Someone is on leave, a day gets missed, and the gap is only discovered at close.
• Typos are invisible. A transposed digit in a rate looks exactly like a correct rate until the variance shows up somewhere else entirely.
• History is awkward. Restating a prior period, or answering an auditor about a shipment from two years ago, means digging through archives rather than making one query.
• Non-publication days trip people up. Weekends and public holidays have no rate at all, and every team invents its own rule about what to use instead — usually without writing it down.

The Bank of Tanzania rates as an API

AllRatesToday ingests Bank of Tanzania’s published table shortly after each release and serves it back in a consistent shape, alongside 95 other central banks and national tax authorities on identical endpoints.

• Official figures, unmodified — served with Bank of Tanzania’s own publication date on every response.
• 38 currencies against the TZS.
• History back to 2010 — query any past date, or pull a full time series.
• Honest holiday handling — non-publication dates resolve to the most recent published table and say so, rather than silently interpolating.
• Formats finance actually uses — JSON, CSV, XML and genuine Excel workbooks, so it lands in a spreadsheet, Power BI or an ERP without a conversion step.
• Published vs derived is labelled — a pair Bank of Tanzania did not print itself is computed from its table and flagged, never passed off as an official quote.

Sample response

A real response for USD to TZS, from Bank of Tanzania’s publication of 2026-08-24:

{
  "bank": "botz",
  "rate_date": "2026-08-24",
  "source": "USD",
  "target": "TZS",
  "rate": 2643.558,
  "rate_type": "reference",
  "derived": false
}

The rate_date is the central bank’s own publication date — the date you cite in the ledger — and derived tells you whether Bank of Tanzania printed this pair itself.

Who this is for

• Exporters and importers converting invoices and customs values at a rate that has to hold up later.
• Finance and accounting teams closing books across currencies.
• Auditors and advisors who need to reproduce a client’s conversion months after the fact.
• ERP, accounting and invoicing platforms that need an official rate feed their own customers can defend.
• Fintech and payments teams that price on market rates but must report on official ones.

What it actually saves

• Time — no one copies rates into a spreadsheet every morning again.
• Accuracy — the figure is whatever Bank of Tanzania published, with no retyping in between.
• Audit risk — every number carries its publication date, so “where did this come from?” has an answer.
• Consistency — every entity, report and invoice converts from the same series.

Getting started

1. Create a free account — 300 requests a month, no card.
2. Call /api/v1/central-bank/botz/latest, or download the table as Excel from the Bank of Tanzania coverage page.
3. Wire it into your close, your invoicing, or a scheduled spreadsheet refresh.

Developers who want the endpoints, SDK and code samples should read the Bank of Tanzania API guide instead — this page is the business case; that one is the integration.

FAQ

Where do Bank of Tanzania exchange rates come from in this API?

Directly from Bank of Tanzania's own published indicative rates. Rates are stored unmodified with the central bank's publication date attached, so the figure in your ledger is the figure Bank of Tanzania printed, going back to 2010.

Can I get the Bank of Tanzania rate for a past date, like an invoice or shipment date?

Yes. Ask for any past date and you get the rate in force then, back to 2010. If the central bank did not publish that day — a weekend or a public holiday — the API returns the most recent published table and flags that it did, so your audit trail stays honest instead of silently guessing.

Do I need a developer to use this?

Not necessarily. Every coverage page offers the latest published table as an Excel or CSV download, and finance teams commonly pull the API straight into Excel, Power BI or their ERP on a schedule. A developer helps if you want it wired into invoicing or your accounting system automatically.

Final thought

Official rates are not a nicer version of market rates — they answer a different question. Market data tells you what a currency is worth right now. Bank of Tanzania’s published table tells you what rate your books, your customs entries and your auditor are entitled to expect for a given date. Getting that second number automatically, with its publication date attached, removes an entire category of month-end argument.