technical · 6 min read

Ethiopian Bank Receipt Formats: A Complete Reference

Every Ethiopian bank receipt reference format, endpoint URL, and response type in one place. CBE, Telebirr, BOA, M-Pesa, Dashen, Awash, Zemen, CBE Birr, Siinqee, eBirr.

This is a complete technical reference for every Ethiopian bank and mobile wallet receipt system. If you're building a verification system, integrating payments, or just want to understand how Ethiopian bank receipts work, this is your reference.

CBE (Commercial Bank of Ethiopia)

CBE has two receipt systems. The new system (mbreciept) is preferred for its clean JSON response.

New system (mbreciept.cbe.com.et)

Old system (apps.cbe.com.et)

Reference format: FT followed by 10 alphanumeric characters. Example: FT26140P01YB

# Old CBE URL construction
FT_REFERENCE = 'FT26140P01YB'
ACCOUNT = '1000560536171'
LAST_8 = ACCOUNT[-8:]  # '60536171'
URL = f'https://apps.cbe.com.et:100/?id={FT_REFERENCE}{LAST_8}'
# https://apps.cbe.com.et:100/?id=FT26140P01YB60536171

Telebirr (Ethio Telecom)

Reference format: 2-3 letter prefix followed by 6-8 alphanumeric characters. Common prefixes:

# Telebirr URL construction
REFERENCE = 'DET8FJGUJ4'
URL = f'https://transactioninfo.ethiotelecom.et/receipt/{REFERENCE}'

Bank of Abyssinia (BOA)

Reference format: Alphanumeric, typically starts with 2 letters. Example: AB12345678 or FT26167ZVPCJ

M-Pesa Ethiopia (Safaricom)

Reference format: Alphanumeric Safaricom transaction reference.

Dashen Bank

Reference format: Alphanumeric Dashen transaction reference. Use the Transaction Reference, not the Transfer Reference. Works for both within-Dashen and Other Bank Transfer (inter-bank) receipts.

Awash Bank

Awash Bank receipts are public HTML pages on awashpay.awashbank.com, served by a Java backend called MoonlightMBanking behind an F5 BIG-IP WAF. We have fully reverse-engineered the share-link structure using 18 real samples collected from SMS messages, GitHub repos, and community contributions. The share link is sent automatically via SMS after every transaction.

Transaction ID structure

The numeric Transaction ID is not random. Since 2026, it has a fixed structure: YYMMDDHHMM followed by a 5-digit per-minute sequence number. For example, Transaction ID 260607112275735 breaks down as:

This means the Transaction ID itself encodes the transaction date and time down to the minute. The 5-digit sequence resets each minute and is not globally monotonic. We verified this against all 13 new-format samples. Transactions before 2026 use a different hex-like format (e.g. E3BF28E4B8C1) that does not follow this structure.

URL structure breakdown

Example share link: https://awashpay.awashbank.com:8225/-2KDL95Z0NR...

We verified this with 18 real Awash receipts spanning April 2025 to June 2026, covering transaction types including Send To Bank, IPS Bank Transfer, Send to Wallet, Telebirr Transfer, Merchant Payment, and Other Bank Transfer. In every case, converting part 1 from base-36 to decimal produced the exact Transaction ID. The URL is case-insensitive (lowercase works).

Counter analysis (18 samples)

Part 2 is not a hash of the Transaction ID. We tested and ruled out: CRC32, Adler32, MD5/SHA1/SHA256 truncation, Java hashCode, DJB2, FNV-1a, HMAC, affine functions, modulo operations, and bit manipulation. It is a monotonically increasing counter with an accelerating rate that correlates with time.

The counter rate is accelerating: 4.4/sec in mid-2025, 6.4/sec by January 2026, and 7.5/sec by June 2026. A quadratic model fits with R-squared = 0.9999 and maximum residual of ±1M. For dates bracketed by nearby samples, local linear interpolation gives predictions within ±100K.

The server strictly validates both segments. Replacing part 2 with a nearby value returns 'Mistmatch / invalid receipt id'. Omitting it returns 'Invalid receipt id'. Part 2 must be exactly 6 base-36 characters (5 or 7 chars returns mismatch). Extra dashes or special characters are rejected by the WAF.

Server architecture

The Awash receipt server runs a Java application called MoonlightMBanking (revealed by the JSESSIONID cookie path). It sits behind nginx and an F5 BIG-IP ASM WAF that blocks all paths except the /-{part1}-{part2} receipt URL pattern. A merchant API exists at /awashbirrpro/merchant-api/ but is also WAF-blocked. The receipt HTML contains no client-side token generation logic: the share URL is pre-baked in the HTML and only used to render a QR code.

Brute-force proof of concept (2 successes)

We have proven that a valid share URL can be constructed from a Transaction ID alone, without the Awash app or SMS, by brute-forcing the counter. We did this successfully twice:

Both scans ran at 66-106 req/sec with zero WAF blocks and less than 0.01% error rate. The server did not rate-limit or block the probing. The April 1 scan was especially efficient because we had a nearby sample from April 2 (just 1 day away) to anchor the prediction.

What we still need to figure out

1. Is the counter global across all Awash transactions, or per branch / per sender / per channel?
2. Why did one Transaction ID (March 28) resist brute-forcing across 8M+ URLs? Was the counter outside our model range, or is there a different explanation?
3. What is the relationship between the old hex-format txIDs (pre-2026) and the new YYMMDDHHMM format?
4. Can the counter prediction be improved with more samples from underrepresented time periods?

How to verify Awash with cheki

Paste the full share link from your Awash SMS or app into cheki. The parser will extract the Transaction ID, receiver, amount, date, and other fields from the official HTML receipt. cheki handles all receipt variants (Transfer successful, Transaction successful, Transaction Details, Telebirr Transfer) including IPS bank transfers, merchant payments, send-to-wallet, and other-bank transfers.

Zemen Bank

CBE Birr

Siinqee Bank

eBirr (Nib, Wegagen, Ahadu, KAAFI)

eBirr is a mobile money platform connecting 5 Ethiopian financial institutions through a single receipt endpoint. Each partner bank has its own tenant code in the URL.

The user shares the receipt from the eBirr app to get a receipt.ebirr.com/{tenant}/{token} URL. cheki auto-detects the tenant and maps it to the correct partner bank. Invalid tokens return a 'Not Found Page' (HTTP 200 with red H1).

Other Ethiopian banks (researching)

The following 18 banks are licensed in Ethiopia but do not yet have confirmed public receipt verification endpoints. cheki lists them as 'in development' and is actively researching their receipt systems:

Auto-detection patterns

cheki auto-detects the bank from the reference format. Here are the detection rules: