How to Verify a CBE Transaction Before Delivery

A CBE transfer can look real in a screenshot and still be unusable for release. For safe fulfillment, verify in a source-of-truth system and match all required fields.

Core rule

A screenshot is a claim. A confirmed CBE ledger event is payment.

Why CBE verification failures still happen

Ethiopia’s digital usage is growing quickly. As volume grows, the chance of rushed release rises, especially when staff are asked to process many incoming payments at short notice.

Step-by-step: verify CBE before release

Step 1 — Pause release immediately

Use a standard phrase:

"We verify every CBE transfer before fulfillment. Please share the full reference number."

Step 2 — Capture structured data

Store at least:

• order/invoice ID
• expected amount
• CBE reference ID
• payment time from customer
• staff member handling verification

Step 3 — Use one official verification path

Choose one source of truth and keep it consistent:

• your own CBE account or statement
• official CBE support flow/portal
• a verified CBE checker integrated in your operations

Avoid switching between channels per order. Consistency matters.

Step 4 — Match required fields

Hold unless all pass:

• reference found
• exact amount
• recipient belongs to your business
• status is settled/completed
• timestamp fits order context
• reference not already used on another order

Step 5 — Record the decision

Log:

• verification result
• reference
• amount
• staff name
• timestamp
• release or hold status

CBE-specific risk checks

1. Cropped or partial references

If the reference is not complete, do not guess. A partial read is an automation weakness.

2. Amount mismatch

Any amount difference must be treated as mismatch unless your policy allows documented partial payment.

3. Duplicate reference use

A reused reference is a common fraud pattern. Do not release a second order until manually investigated.

4. Pending/silent status

Pending is not done. Keep the order on hold until success status is confirmed.

Status definitions for your team

• unverified: initial image or claim only
• pending: reference exists but not settled
• verified_match: all fields match and payment is settled
• amount_mismatch: reference exists, wrong amount
• duplicate_suspect: one reference used before
• not_found: no matching record
• reversed_or_failed: failed settlement or reversal

CBE support and escalation

Use official CBE support channels shown on their own site and internet banking pages. If you need formal escalation:

1. retry verification with exact input,
2. escalate to bank support,
3. file formal complaint path if unresolved through your regulator’s complaint process.

Delivery, logistics, and rider workflows

• riders should not approve or force release on screenshot alone
• only central verification with verified_match should unlock dispatch
• large orders: add second-person approval or audit review

Implementation example for a small business

1. Train one SOP script
2. Keep a printed checklist near the counter
3. Set a daily reconciliation time at closing
4. Escalate unresolved reference cases in a batch with logs

This keeps your fulfillment fast while removing the biggest fake-payment leak.