When allowances are created, they can represent certain volumes of service usage or values that the customer has paid, but not yet received the services for. The company offering the service is therefore still owing the service delivery but has already received money for it. Legally, the money usually cannot be posted as revenue, but must be defined and posted as "deferred revenue". SAP FI-CA supports two types of deferred revenue:
- Event-based deferred revenue
- This category of deferred revenue, assumes that the price for the service that is owed by the service provider is calculated based on usage. This is the case when consumption items represent the usage of a service, which are rated by SAP Convergent Charging.
- Time-based deferred revenue
- This category of deferred revenue assumes that the price for the service, that is owed by the service provider, is calculated based on time. This is the case when fees for the service are due on a recurring basis. SAP Convergent Invoicing usually handles these kinds of fees by means of billing plans. SAP Convergent Charging is not involved in this case.
For allowances, only the event-based type is relevant.
When dealing with event-based deferred revenues, an allowance can be defined in two ways:
- Amount-based
- An allowance can represent the right to consume services up to a certain value. For example, an allowance can represent the right to consume network traffic worth up to 100,- €.
- Quantity-based
- An allowance can represent the right to consume a certain number of units of a certain service. For example, an allowance can represent the right to consume 30 GB of network traffic within a period one calendar month.
When dealing with deferred revenue, it must be decided which of the types of deferred revenue will be managed.
SAP Convergent Charging supports the automatic posting of deferred revenues in SAP Convergent Invoicing. In SAP Convergent Invoicing, the billable item class needs to have the interface component "Deferred Revenues - Event-Based" activated. Along with this interface component, the following fields are added to the billable item class.
Fields Added to the Billable item Class
| Field | Name |
|---|---|
| ALLOWANCE | It indicates whether a billable item (BIT) is created within the context of the processing of an allowance defined in a provider contract.
|
| DEFREV_CAT | Category of Deferred Revenues The category can be time-based ("01") or event-based ("02"). For allowances, only event-based revenue recognition is relevant. |
| DEFREV_PDATE | Transfer posting date for deferred revenue |
| DEFREV_ACTION | Action code for posting event-based deferred revenue |
| DEFREV_CTYPE | Cost Type/Revenue Type It determines the account and the deferred revenue calculation base (amount or quantity). |
| DEFREV_ASSKY | Assignment Key This field contains the allowance ID. |
Besides these new fields, the fields BIT_QUANTITY, BIT_AMOUNT and BIT_CURR are relevant.
Usually the lifecycle of an allowance has two important phases with regards to deferred revenue:
- Creation of deferred Revenue
- Realization of deferred Revenue
Let’s see how these phases map to the various steps in the allowance lifecycle.
Posting of Deferred Revenue
With the creation of the allowance, money is paid by the customer to the service provider. This amount has to be posted completely as deferred revenue. It has to be associated with the allowance and the associated reference quantity, which can either be a quantity expressed in service units (like 100 GB of traffic) or a monetary amount expressed in a currency (1250,- €).
Example: A customer purchases an allowance with an initial amount of 1000,- € and a bonus amount of 250,- € for 1000,- €. Then 1000,- € of deferred revenue is posted and associated with 1250,- € of value for the customer. In other words: The allowance represents the right for the customer to consume services of a value of 1250,- € within a period of two months. The service provider charges the customer 1000,- € for this right.
Revenue Realization
As the customer consumes services, the consumption is settled against the allowance balance. Let’s assume the customer consumes services worth 125,- €. This value is settled against their allowance balance. The balance is reduced by 125,- € from 1250,- € to 1125,- €. As this consumption represents 10% of the balance, 10% of the deferred revenue can be resolved and posted as realized revenue. The deferred revenue thus reduced from 1000,- € to 900,- € while revenue increases by 100,- €.
When the allowance expires before the customer consumed all of its balance, the company can realize the remains of the deferred revenue. Let’s assume the customer still has 125,- € of balance in the allowance when it expires. SAP Convergent Charging can reduce the balance to 0,- € and report the amount that expired to SAP Convergent Invoicing. There, the corresponding postings are made based on the amount that was reported as expired with reference to the allowance.
Overview of Involved Steps
| Allowance Step | Description | Custom Logic Example | BIT Types in Training Landscape | Revenue |
|---|---|---|---|---|
| Creation | Created by the Charging / Refilling process as a provider contract data. Allowance has the inactive state. | Initializing the bucket | PA01 (Allowance Create) | 01 Create FI-CA Deferred Revenue |
| Activation | Start of the validity period Allowance has the active state. | Generating a notification for the customer | PA02 (Allowance Activate) | - |
| Use | Used by the Charging / Refilling process within the validity period | Debiting the bucket | PA03 (Allowance Use) | 02 |
| Expiration | End of the validity period Allowance has the expired (inactive) state. | Reporting the lost credit | PA04 (Allowance Expiration) | 02 FI-CA Deferred |
| Purge | Removal of the expired allowances from the provider contract exceeding a given retention period | n/a | n/a | n/a |
The table provides an overview of the various steps involved. Some of the steps, however, are not important for the management of deferred revenue, but can be used for information purposes:
- During activation of an allowance, the deferred revenue is not touched. You can use this event, however, to inform the customer about the availability of the balance.
- The purge step does not have an implication to deferred revenues, as it simply removes allowances that are not needed anymore.