Credit revenue & breakage

How cash received for prepaid credits becomes revenue as those credits are consumed, and how to account for credits that expire unused.

Why this matters

Selling credits separates the cash from the service. A customer who buys 10,000 credits has paid you today for a service you have not delivered yet, so the payment is not revenue: it is a liability you settle by letting them consume credits. Getting this wrong overstates revenue in the month of the sale and understates it for every month after.

Some of those credits are never consumed. The portion that expires unused is breakage, and it becomes revenue at the moment the obligation to deliver disappears.

How it works

A credit sale moves through three states:

The value of a consumed credit is the grant’s paid_amount divided by its granted credits. A 10,000-credit grant bought for $1,000 recognises $0.10 of revenue per credit consumed. Free and promotional grants carry a paid_amount of zero and therefore recognise no revenue when consumed; they reduce the credits available to charge against, not the deferred balance.

Getting the numbers

Solvimon does not expose a deferred-credit balance or a breakage figure as its own object. You assemble both from two sources:

• The revenue recognition report for recognised and deferred revenue per month. See Revenue Recognition.
• Wallet grants and balances for the credits side: GET /v{version}/wallet-grants gives you grant_credits, paid_amount, start_at and expire_at per grant, and the wallet balance endpoint gives you what remains.

1
curl https://api.solvimon.com/v1/wallet-grants \
2
     -H "X-API-KEY: <apiKey>"

1
{
2
  "data": [
3
    {
4
      "object_type": "string",
5
      "id": "string",
6
      "customer_id": "string",
7
      "billing_entity_id": "string",
8
      "wallet_id": "string",
9
      "type": "DEFAULT",
10
      "description": "string",
11
      "grant_amount": {
12
        "quantity": "string",
13
        "currency": "AED"
14
      },
15
      "grant_credits": {
16
        "quantity": "string",
17
        "credit_type_id": "string"
18
      },
19
      "paid_amount": {
20
        "quantity": "string",
21
        "currency": "AED"
22
      },
23
      "start_at": "2024-01-15T09:30:00Z",
24
      "expire_at": "2024-01-15T09:30:00Z",
25
      "created_at": "string"
26
    }
27
  ],
28
  "links": {
29
    "first": "string",
30
    "previous": "string",
31
    "current": "string",
32
    "next": "string"
33
  },
34
  "limit": 1,
35
  "page": 1,
36
  "total_number_of_pages": 1
37
}

The deferred balance on a grant at any date is:

deferred = paid_amount x (credits remaining / grant_credits)

Because credits are consumed earliest expiry first, the credits remaining on a specific grant are not simply the wallet balance. Pull the grant list and the wallet balance for the same balance_at date and allocate in expiry order.

Recognising breakage

Breakage recognition is driven by the grant’s expire_at:

1. On the first day after expire_at, read the grant’s remaining credits.
2. Value them at the grant’s per-credit rate.
3. Post that amount out of deferred revenue and into revenue, dated to the expiry period.

Run this as part of month-end close alongside the recognition report, so the two together give a complete deferred revenue balance: invoiced-but-unearned subscription revenue from the report, plus unconsumed prepaid credits from the wallet grants.

Edge cases

• Grants that are extended rather than allowed to expire keep their deferred balance. Nothing is recognised until credits are consumed or the new expiry passes.
• Rollover top-ups carry the balance into the next period, so no breakage arises at the period boundary. See the rollover section in Credit consumption & expiry.
• Refunding an unused top-up removes the liability rather than recognising it. Issue a credit note against the top-up invoice.