Revenue recognition

Zenskar is ASC 606- and IFRS 15-compliant.

Although ASC 606 and IFRS 15 have some differences, both establish the principles that an entity applies when reporting information about the nature, amount, timing and uncertainty of revenue and cash flows from a contract with a customer.

Applying either standard, an entity recognizes revenue to depict the transfer of promised goods or services to the customer in an amount that reflects the consideration to which the entity expects to be entitled in exchange for those goods or services.

Both ASC 606 and IFRS 15 have defined a 5-step model for revenue recognition:

  1. Identify the contract
  2. Identify separate performance obligations
  3. Determine the transaction price
  4. Allocate transaction price to performance obligations
  5. Recognize revenue when each performance obligation is satisfied

⚙️ Step 1: Identify the contract

📚

Note

All contracts created in Zenskar are inherently ASC 606- and IFRS 15-compliant. There is no further action required of you.

Let us build an example contract that contains the following three products:

ProductDescription
Platform annual feeA prepaid, recurring flat fee of $3600 per year for access to the platform.
Implementation feeA one-time implementation fee of $600.
Extra seatsA fee of $10 per seat for 60 extra seats.
Fig. 1: The contract.

Fig. 1: A Zenskar contract is inherently ASC 606- and IFRS 15-compliant.


⚙️ Step 2: Identify separate performance obligations

Performance obligation (PO) is your promise to transfer goods or services to your customer. During this step, you should itemize every distinct PO. A service or product is considered distinct when it is of value to the customer and can be transferred independently of other services or products in the contract.

📚

Note

Identifying POs will result in the unbundling of a contract into POs. This is a crucial step to recognize revenue correctly.

📚

Note

The following are examples of circumstances which do not give rise to a PO:

  • providing goods at scrap value
  • activities relating to internal administrative contract set-up

Add performance obligations in Zenskar

  1. To add POs from the contract mentioned in Step 1, navigate to Contracts.
  2. Click on the kebab menu located at the end of the row containing the contract you are interested in.
  3. Click on the Revenue Recognition menu option, as shown below:
  1. The Performance Obligations page is displayed.
  1. Add the desired POs by clicking on the + ADD PERFORMANCE OBLIGATION button.

Continuing with the example: add performance obligations

The contract mentioned in Step 1 has three distinct products that could result in the contract unbundling into three potential POs:

  1. Platform annual fee
  2. Implementation fee
  3. Extra seats

📚

Note

There are circumstances that could result in services or products being combined into a PO. For example, if one service or product depends on the price or performance of another service or product, you may consider combining them into one PO.

In the current example, one potential PO, Platform annual fee, is dependent on the performance of another potential PO, Implementation fee. Therefore, it makes sense to combine them.

Let us add two POs:

  1. Platform access: this PO has the following products serving as value sources.
ProductPercentage
Platform annual fee100
Implementation fee100
Performance obligation parameterDetails
NameAny descriptive string that uniquely identifies the PO.
DescriptionDescribe your PO.
PO periodOver what period do you expect the customer to make the payment?
PO policyRefer the documentation on PO policies.
Value sourceThe products that contribute value to the PO:
• a PO may have multiple products as value sources
• multiple POs may share a portion of the value of a product
  1. Extra seats: this PO has only one product serving as value source.
ProductPercentage
Extra seats100

📚

Note

Identifying POs is entirely dependent on the circumstances under which your business operates. Therefore, Zenskar provides you the necessary tools and lets you decide how to identify POs.

View performance obligations

  1. To view the POs from the contract mentioned in Step 1, navigate to Contracts.
  2. Click on the kebab menu located at the end of the row containing the contract you are interested in.
  3. Click on the Revenue Recognition menu option, as shown below:
  1. The list of POs associated with the contract will be displayed, as shown below:

Edit performance obligations

A PO has two revenue plans associated with it:

  1. Default actual plan for the PO
  2. Default forecast plan for the PO

🚧

NOTE

Currently, all POs have an actual and a forecast revenue plan. However, the forecast revenue plan is applicable only to metered products. The forecast revenue plan will be removed from non-metered POs in a future release.

The following fields can be edited in a revenue plan:

FieldDetails
Start dateThis date can be different from the contract start date. For example, the implementation of your service or product may not be trivial and may take a couple of months. You can choose to start recognizing the revenue two months after the invoice creation.
End dateThis date can also be different from the contract start date based on your special circumstances.
Revenue distribution methodRefer the documentation on revenue distribution methods.
Revenue config change impactIf the end date of a PO is edited, the revenue plan is affected. There are two ways of handling this change:
update all periods: revenue postings are considered loked if they have already been recognized and corresponding journal entries created. Locked revenue postings cannot be altered. However, the changes affecting such locked revenue postings can be redistributed over the remaining periods using any revenue redistribution method supported by Zenskar. For example, if the revenue postings for January, 2024, through August, 2024, have been recognized, any changes affecting these postings can be redistributed in the revenue postings of September, 2024, through December, 2024.
update remaining periods: for changes that do not affect the locked revenue postings, this method can be used.
Revenue redistribution methodIn the event of a change in the end date of a revenue plan, the following revenue redistribution methods are supported:
straight-line
front-loaded
back-loaded
Deferral accountThe revenue account where deferred revenue is posted.
Revenue account

⚙️ Step 3: Determine the transaction price

Transaction price is the most likely value that you expect to be entitled to in exchange for the promised services or products supplied under a contract. The product definition will contain the transaction price necessary for revenue recognition.

Fig. 1: Platform annual fee as product.

Fig. 4: "Platform annual fee" as product.

Fig. 2: One-time implementation fee as product.

Fig. 5: One-time "implementation fee" as product.

Fig. 3: Extra seats as product.

Fig. 6: "Extra seats" as product.


⚙️ Step 4: Allocate transaction price to performance obligations

Allocate transaction price to each PO on the basis of the relative stand-alone selling prices of each distinct service or product promised in the contract. Continuing with our example, the following two POs can be created:

  1. Platform access: this PO has the following products serving as value sources.
ProductPercentage
Platform annual fee100
Implementation fee100
  1. Extra seats: this PO has only one product serving as value source.
ProductPercentage
Extra seats100

You can create more POs, view and edit POs associated with a contract:

📚

Note

Identifying POs is entirely dependent on the circumstances under which your business operates. Therefore, Zenskar provides you the necessary tools and lets you decide how to identify POs.

⚙️ Step 5: Recognize revenue when each performance obligation is satisfied

Fig. 9: Invoice.

Fig. 9: Invoice.

The invoice has resulted in a journal entry that has credited the deferred revenue and debited the accounts receivable for $4800.

Fig. 10: Journal entry created upon invoice approval.

Fig. 10: Journal entry created upon invoice approval.

If we perform revenue recognition of the Platform Access performance obligation for a single month and post the revenue to the general ledger, we will see the following journal entry.

Fig. 11: Journal entry created on revenue recognition of the Platform Access performance obligation for a single month.

Fig. 11: Journal entry created on revenue recognition of the Platform Access performance obligation for a single month.