Revenue reporting methodology

Orb’s reporting functionality is designed to help your team simplify your month close process with revenue reports (such as for recognized and deferred revenue) and drive your receivables activities.

Orb’s revenue reporting is built with the following principles in mind:

1. Completeness: It must be possible to account for all revenue that the billing engine produces. In other words, all features supported by the Orb billing engine will have corresponding revenue accounting treatment.
2. Consistency: The way that Orb recognizes revenue is always consistent with how invoices are produced. For example, the proration methodology between billing and revenue recognition does not diverge.
3. Auditability: Whether it’s through the Orb API, data exports, or in-product drill down and split views, Orb’s product is committed to providing the lineage of revenue from a summary entry → invoice → raw product usage data.

Recognized revenue methodology

Orb automatically calculates recognized revenue in a way that accords with ASC606 guidelines. Orb’s reporting module handles the full sophistication of Orb’s billing engine, including support for a broad range of usage-based models, prepaid commitments, multiple cadences, and multiple currencies. This section outlines the methodology in the abstract, and the following section covers some illustrative examples.

For businesses with a usage-based component to their pricing, calculating recognized revenue can be challenging, as it requires understanding exactly when usage occurs. This can be particularly difficult when invoicing and accounting periods do not align, or for cases like credit drawdowns where invoices may not contain the required information for recognition.

An important principle is that Orb guarantees that your recognized revenue always converges to your billed revenue over time. In other words, the amount of revenue that is recognized up to a given date should be consistent with the billing that results in all relevant subscriptions ending on that date. This ensures deferred and unbilled revenue balances reach zero for a customer once all their subscriptions are ended and their prepaid credits are exhausted or expired.

Orb’s billing engine supports both usage-based fees (e.g. compute, storage, or API requests) as well as fixed fees that are not tied to event reporting (e.g. support fee or platform fee). Note that per standard accounting guidelines, revenue numbers always exclude tax and the payment status of an individual invoice is not factored into accounting treatment.

Usage-based fees

Revenue is recognized for usage as it occurs on a daily basis, regardless of the associated line item’s service period. Each usage event is reported to Orb with a timestamp property, which determines the time that the event happened. For billing, invoicing, and reporting purposes, this determines the time attribution of the corresponding usage.

Note that this recognition behavior is maintained whether or not the usage-based charge leads to an accrual on the invoice or whether it causes drawdown of existing prepaid credits.

Prepaid credits

Prepaid credits are a way for your customer to commit to a certain amount of usage and draw it down through their subscription over time.

Recognition for credits is always based on their cost basis, which represents the unit price at which they were purchased. Credits are added to your customer in ‘blocks’, and each block can have a separate cost basis. For example, free trial credits may have a cost-basis of $0 and hence no revenue would be recognized by their consumption. An enterprise customer might commit to $1.6M of custom platform credits over the year at the cost of $800K, determining a cost basis of $0.50/unit.

Prepaid credits typically have an effective date as well as an expiration date. Orb adheres to the following recognition rules: No revenue is automatically recognized when the prepaid credits become effective. At this point, all of the revenue should be considered deferred revenue because no service obligation has been met. As stated above, revenue is recognized on a daily basis when usage occurs, derived from how many credits are used in that day based on incurred usage. When a credit block expires, its remaining balance is recognized on the expiration date.

Note that prepaid credits can either be in a custom currency (e.g. "custom credits unit") or in a real-world monetary currency (e.g. USD). In either case, the cost basis is used to translate the credit burndown amount to the revenue that should be recognized.

In some cases, it might be preferable to straight-line recognize the revenue from credits based on the time period that they’re effective, instead of using the burndown approach described above. This is more common in cases where the service delivery is tied more closely to platform access rather than marginal credit units. Orb provides this behavior by allowing you to combine an in-advance fixed-fee with $0 cost basis credits, also called an allocation. Note that credit consumption then does not contribute to recognition, and the fixed fee will be straight-lined (see below).

Fixed fees

Orb’s billing engine has support for fixed-fees, such as seats, support, or platform access. Each fixed-fee is associated with a service period, typically corresponding to the start date of the billing period, the cadence, and whether the fee is billed at the end of the period or in advance.

By default, Orb performs proration on fixed fees, meaning that any partial period will result in a partial charge on the invoice. In order to calculate recognized revenue, Orb performs straight line recognition, recognizing revenue on a daily basis. For example, for an up-front platform fee of $960 in a 30-day month, Orb will recognize $960/30 = $32 each day. Note that this is true whether this fee is charged in-advance of the month or in-arrears; in either case, the same prorated amount will be recognized each day.

Actions in the past

It’s common to take backdated actions in Orb, such as subscription creation, edits to a subscription’s plan, or subscription cancellations.

When a backdated action, such as creating a subscription starting in the past, results in a new invoice being created, Orb automatically captures usage that’s been ingested for that invoice. Revenue recognized for that action will reflect the service periods on the newly generated invoice, adjusting the data for those previous days.

An action like a backdated cancellation can cause Orb to regenerate an invoice for a shortened billing period. In this case, the original invoice’s recognition is no longer valid; the new invoice may not capture the same set of line items or the full set of usage. To accommodate this class of action, Orb reverts the recognition data from the original invoice and regenerates recognition according to the new invoice’s line items. All actions that change the state of the subscription in a way that’s not consistent with the current subscription will lead to reverting existing revenue events.

Subscription adjustments (minimums, discounts, maximums)

It’s common in usage-based businesses to have significantly more sophisticated adjustment mechanics, such as enforcing a minimum or a maximum on a given usage-based line item. In Orb, an adjustment like this can also apply to multiple items at once, such as a minimum that applies for a whole invoice consisting of different usage-based charges.

Revenue is recognized in the following way:

1. Minimum amounts are recognized on a daily basis (similar to fixed-fees), and are recognized proportional to how much the original line item contributes to the invoice total.
2. Percent-based discounts reduce the recognized amount of their underlying prices by the percent. No proration logic is necessary.
3. Amount-based discounts reduce the recognized amount of their underlying prices, on a daily basis, proportional to the amount of the underlying line items.

Automatically created credit notes

A credit note can be created on an issued or paid invoice, and is automatically created by the billing engine on invoices containing in-advance fees that are no longer expected based on the state of the subscription. For example, a mid-period cancellation involving an in-advance fee will result in a reduced, prorated expected payment and will require a correction in the form of a credit note on the previously issued invoice.

In the case that a credit note is generated automatically in order to account for the shorter period, all revenue past the cancellation date is reversed and no longer eligible to be recognized.

Revenue handling of manual actions

Invoice edits

Since Orb features a full invoicing engine, Orb allows you to edit draft invoices through an adjustments process, giving you the flexibility to add discounts or create new line items on an invoice before it has been issued. Invoice edits are considered ‘backdated’ actions in the sense that revenue adjustments will be recognized based on the service period of the invoice line item.

Manual credit notes

When creating a credit note manually (e.g. in the case of an overcharge), the amount that is unrecognized from the original invoice is the amount on the credit note. The date range over which the revenue is recognized is taken from the service period of the original line item, and spread evenly across the service period.

Deferred revenue

Orb provides a deferred revenue report separate from recognized revenue. Conceptually, your deferred revenue is your liability to your customer – it’s a pending service obligation that you are not yet able to recognize because the service hasn’t been delivered. In Orb, your deferred revenue is the amount that has been invoiced (excluding tax) that has not yet been recognized.

The most common reasons for deferred revenue are:

1. Unused prepaid credits. Deferred revenue is calculated based on the cost-basis of these credits. Note that only credits created with an associated invoice should be treated as deferred revenue, whether or not the corresponding invoice has been issued. If your customer receives an annual credit allotment but pays for them over the course of a year on a quarterly payment schedule, the deferred revenue should increase for all credits at the beginning of the year.
2. In-advance fixed-fees. For example, an annual platform fee should be recognized on a prorated daily basis over the course of the year. Correspondingly, the deferred revenue account is initially the full fee and then is depleted each day.

Deferred revenue can automatically be adjusted as the result of a subscription action, such as a mid-period cancellation where the fixed-fee is credited back to the original invoice. In this case, revenue recognition will no longer take place for that price and there will be no corresponding deferred revenue remaining.

Billed revenue

Billed revenue is defined specifically based on the invoices that have been issued. Similar to recognized and deferred revenue, Orb tracks billed revenue on a per-customer and line item basis, so it can be attributed to the most granular level. Billed revenue, since it is based on invoice issuance, only increases once when the invoice is issued, rather than on a continuous basis. If your account is set to manually issue invoices, billed revenue will not increase until the invoice is manually issued.

When an invoice is voided or a credit note is issued against an invoice, Orb reduces the billed revenue.

Unbilled revenue

In traditional subscription businesses, it’s common to charge everything up-front, meaning that revenue recognition is conceptually a subset of billed revenue. However, usage-based businesses commonly accrue revenue on ‘draft invoices’, implying that revenue must be recognized before it’s billed. This is your “unbilled” revenue.

The most common cases where you should expect unbilled revenue are:

1. Usage-based charges: At any given point in time, your draft invoices in Orb will be accruing usage based on the events sent into the platform. Although these invoices haven’t been issued, Orb is still accruing unbilled revenue.
2. In-arrears fixed-fees: For example, suppose you charge a monthly support fee at the end of each month. Orb will recognize this revenue as the month progresses even though the fee has not been billed.

Deferred revenue and unbilled revenue should always be considered on a per-line item basis. In particular, it’s possible for a customer to have both deferred revenue and unbilled revenue (see below) on different fees. To take the simplest case, the current period might have a $100 in-advance and $100 in-arrears fee. At any given point in time, this customer will have both partial deferred revenue (corresponding to the in-advance fee) and recognized, unbilled revenue (corresponding to the in-arrears fee).