Recognition 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. Allocations and cost basis Allocations (recurring credits added automatically as part of a subscription) can be configured with either a zero or non-zero cost basis:

• Zero cost basis allocations: These represent free inclusions in a plan and do not generate revenue. No revenue is recognized when these credits are consumed, as they have no associated cost. This is common for trial credits or plan-included allowances.
• Non-zero cost basis allocations: These represent recurring commitments where customers are charged for the allocated credits. Revenue is recognized as the credits are consumed, using the same burndown methodology described above. For example, if a customer receives 5,000 credits per month at a cost basis of $0.25/credit, the $1,250 charge is initially treated as deferred revenue and recognized as the credits are used.

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 (an allocation). With this configuration, credit consumption 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. 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). The outstanding minimum amount to be recognized is distributed evenly across all relevant line items on the impacted invoice.
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 an accrued daily basis, up to the total discount amount.

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.

​

Actions in the past and accounting period locks

It’s common to take backdated actions in Orb, such as issuing one-off invoices, creating new subscriptions, editing a plan, or cancelling a subscription in the past. When a backdated action results in a new invoice being created, Orb automatically captures usage that’s been ingested for that invoice. How that revenue is recorded in Orb depends on the lock posture of the monthly accounting periods in Orb. Accounting period locks allow you to control when and how revenue is recognized. Closing an accounting period ensures that there will be no subsequent changes to that period in any Orb Reports due to changes in billing activities.

• When the monthly accounting period is open:
  • Revenue from new invoices entered into the period will be recognized in the service period on the newly generated invoice, updating the amounts for those days.
  • Billings from new invoices entered into the period will be recorded on the issuance date of the newly generated invoice, updating the amounts for those days.
  • Deferred revenue calculated for the period will use the updated Revenue and Billings amounts.
• When the monthly accounting period is closed:
  • Revenue from new invoices entered into the period will be recognized on the first day of the next open accounting period as a “catch-up” adjustment. Revenue in previous periods remains unchanged.
  • Billings from new invoices entered into the period will be recorded on the first day of the next open accounting period as a “catch-up” adjustment. Revenue in previous periods remains unchanged.
  • Deferred revenue calculated for the period will use the previous Revenue and Billings amounts. Revenue in previous periods remains unchanged.

Setup Account Admins can lock and unlock accounting periods in Orb from the Reports tab in Settings, and update the fiscal year offset for Reports.

• Accounting periods in Orb are monthly.
• Open and closed periods cannot overlap. All open periods must be sequential and come after closed periods.
  • Reopening a closed period will also reopen any following closed periods to ensure open periods are after closed periods.
  • Closing a period will also close any prior open periods.

​

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 will be recognized during the line item service period if the accounting period is open. If the accounting period is closed, it will be recognized on the first day of the next open period. 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, if the accounting period is open.

​

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

The Billings report in Orb captures the total amount due from invoices for a given time period. Orb determines which billing period to record the transaction, using the invoice date. When an invoice is voided or a credit note is issued against an invoice, Orb reduces billings by recording negative revenue in the relevant period, in accordance with the posture of the accounting period lock at the time of the void action, or credit note issuance.

​

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 a $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).