Skip to content

Delivered data: counting gigabytes, not just sales

The Routegate team5 min read

A thousand sales of a 1GB plan is not always a thousand gigabytes. Delivered data adds up what was actually delivered, from receipts, and says plainly what it could not count.

Ask a data business how much it sold last month and you will usually get a count of sales and a sum of money. Ask how much data it delivered and the honest answer is often a guess: the number of 1GB sales, times one gigabyte, plus the number of 2GB sales, times two.

That guess is wrong more often than people think. A share that delivered part of its size, a gift whose carrier answer gave a different volume, a plan whose size was edited after the sale: each one quietly moves the real number away from the multiplied one. And the real number matters. It is what you reconcile against the data you bought, what tells you which lines are carrying the business, and what you show a customer who asks where their volume went.

Delivered data is the report that counts it properly.

Counted from receipts, never from plan sizes

When a data sale is delivered, Routegate keeps a receipt of how much it delivered, where there is one to keep:

  • a single share delivered in full, or a share a balance check on the line confirmed;
  • a gift whose line plan has a known size;
  • a vendor sale, which keeps the size of the vendor plan that served it.

Delivered data adds up those receipts and nothing else. A successful sale with no receipt is not given a size from its plan, its price or today's catalogue. It is counted, separately, as a sale of unknown volume. The report tells you how many of those there are rather than hiding them inside a total that looks complete.

A number we cannot stand behind is not in the total. It is next to it, labelled.

That rule has a cost. The receipts for gifts and vendor sales were added for sales made from that change onwards, and earlier sales of those kinds were not back-filled with an estimate, so they stay in the unknown column. We would rather a report says "fifty sales, size unknown" than invent fifty gigabytes.

What counts as delivered

A sale counts when it was successful at the moment the report was run and had not been refunded or reversed by then. The report says what that moment was, so two people running it a minute apart can see why their numbers differ. A partial success, a share that delivered some of its size before a line ran out, counts once, with what it actually delivered.

Volumes are kept in whole megabytes. Gigabytes are a display, and the report says how many megabytes it uses to the gigabyte: 1024, every time, never 1000.

Reading the report

In the dashboard it is under Reports, Delivered data: a total for the period, then one row per plan as it was sold. Your own vendor-only plans get rows of their own, so a bundle you sell through your vendors is never folded into one of ours. Filter by network, by plan, or by date, and switch between live and test.

The dashboard reads it from one endpoint:

GET /v1/reports/data-delivery
 curl "https://api.useroutegate.com/v1/reports/data-delivery?from=2026-10-01&to=2026-10-24&network=mtn" \
  -H "Authorization: Bearer $DASHBOARD_SESSION"
The shape of the answer
 {
  "success": true,
  "code": "OK",
  "message": "OK",
  "data": {
    "as_of": "2026-10-24T09:00:00Z",
    "mb_per_gb": 1024,
    "totals": {
      "successful_sales": 120,
      "known_volume_sales": 115,
      "unknown_volume_sales": 5,
      "partial_sales": 1,
      "delivered_mb": 122880
    },
    "items": [
      {
        "sold_as": "plan",
        "network": "mtn",
        "product_code": "MTN-SME-1GB",
        "plan_name": "MTN SME 1GB",
        "requested_mb": 1024,
        "successful_sales": 80,
        "known_volume_sales": 78,
        "unknown_volume_sales": 2,
        "partial_sales": 1,
        "delivered_mb": 79360
      }
    ],
    "page": { "next_cursor": null, "has_more": false }
  }
}

The numbers are an example of the shape, not anyone's month. Read a row from left to right and it tells its own story: what the plan asked for, how many sales succeeded, how many of those have a receipt, and how much the receipts add up to. When known_volume_sales equals successful_sales, the row's delivered_mb is complete. When it does not, the gap is the number of sales you cannot vouch for, and you know exactly how big it is.

The report belongs to the dashboard, for people with permission to read reports. It is not on the API-key API, because it is a question an operator asks about the business, not one an integration asks about a sale.

One line at a time

Add a line to the query and the report answers for that line alone: the data sales it delivered or took part in, each with that line's own share of the volume.

That last part matters for composite shares, where one Data Share is split across several of your lines at once. Each line's part is measured from that line's own running total of data shared, the total after the operation less the total before it. So a 2GB composite across two lines counts on each line for what that line actually sent, and the two add up to the sale.

This is the view for deciding which lines are worth topping up and which are coasting. A line that carries a third of your volume on a tenth of your sales is a line to keep full.

Why we built it this way

It would have been easy to ship the multiplied number. It is always complete, it always looks right, and nobody would have noticed for a while. But the first time a business compared it against the data it bought from a carrier, the two would disagree, and from then on neither number would be trusted.

Counting from receipts, and saying out loud what has none, means the total can be smaller than you hoped. It also means it is true, and it gets more complete as more of your sales carry receipts, not less honest.

It covers data only. Airtime is counted in naira on every transaction already, so there is no volume to reconstruct.

Airtime, reimagined.
Routing, today.