1. Introduction

In SAP BRIM projects, revenue recognition requirements often lead toward SAP Revenue Accounting and Reporting (RAR), and in many cases for a good reason. RAR is designed to meet accounting standards such as IFRS 15 and US GAAP ASC 606, where recognition is driven by performance obligations, contract-based accounting, and transaction price allocation, rather than just invoicing.

But there is another standard capability within Convergent Invoicing (CI) and FI-CA that is often overlooked during solution design, called time-based deferred revenue processing. In the right scenarios, it provides a simple way to handle unearned revenue over time, without introducing an additional revenue accounting subledger that comes with RAR.

To be clear upfront, CI Deferred Revenue is not a replacement for RAR. It does not cover IFRS 15 / US GAAP ASC 606 compliance, and it is not designed for performance obligation based recognition.

Instead, it is a CI/FI-CA capability for time-based revenue deferral, where revenue is recognised at invoicing, then reclassified and released to the P&L over time based on a predefined schedule.

This works well with high-volume subscription billing scenarios where the revenue patterns are known upfront and there is no need for complex allocation logic.

 

2. Technical implementation

This article focuses on time-based deferral used in subscription-based BRIM scenarios where revenue is recognised over predefined schedule defined at invoicing.
For completeness, CI also supports event-based deferral, which is used in consumption-based billing models where revenue recognition is triggered by business events rather than a fixed schedule.

 

2.1. Scenario

A customer buys a 12 month subscription for USD 1,200, billed upfront.

• Billing period: 15 Apr 2026 – 14 Apr 2027
• Posting date: 15 Apr 2026
• Total invoice: USD 1,200
• Monthly revenue: USD 100

What happens from an accounting perspective?

At invoice posting, the full amount is billed and recognised in revenue. The unearned portion is then reclassified to deferred revenue and released monthly to the P&L over the duration of the subscription.

 

Line	Apr 26	May 26	Jun 26	Jul 26	Aug 26	Sep 26	Oct 26	Nov 26	Dec 26	Jan 27	Feb 27	Mar 27
Receivable (Dr)	1,200
Unearned (Cr)	-1,100	-1000	-900	-800	-700	-600	-500	-400	-300	-200	-100	0
Revenue (Cr)	-100	-100	-100	-100	-100	-100	-100	-100	-100	-100	-100	-100

Figure 1 Revenue Schedule 

 

2.2 Configuration

The configuration activities are straightforward, coming down to three steps.

 Activate deferred revenue interface in BIT

This enables the transfer of deferred revenue related data into BIT and activates CI deferred revenue processing.

Figure 2 BIT Interface component

 

Enable deferred revenue in the invoicing process

Assign the invoicing function DEF_REVENUES to the relevant invoicing process.

SPRO-> Financial Accounting -> Contract Accounts Receivable and Payable -> Business Transactions -> Convergent Invoicing   -> Invoicing  -> Invoicing Processes  -> Define Invoicing Processes

Figure 3 SPRO: Maintain invoicing function

 

Configure deferred revenue postings

Define account determination (mapping deferred revenue to revenue GL accounts) and FI-CA document type used for the transfer posting.

SPRO-> Financial Accounting -> Contract Accounts Receivable and Payable -> Business Transactions -> Deferred Revenue Postings

Figure 4 SPRO: Deferred Revenue Configuration  

2.3 FI-CA Event 2615

This is the most important part. Event 2615 is where all the revenue recognition logic is defined. At runtime, the event receives billing, invoicing, and FI-CA document data as input and returns a revenue recognition schedule with dates and amounts. The final schedule is stored in the table FKKDEFREV and processed via mass activity T-code FPDR.

Figure 5 Sample FM in event 2615    

 

In simple terms, Event 2615 is where you translate business rules into a fixed schedule for revenue recognition.

Functional design decisions:  

When designing the logic, the following areas must be defined:  

• Item filtering logic: define which billing types and products are in scope. Typically, one-off charges or non-subscription items are excluded.
• Period determination:  define how contract periods are derived from billing dates and how partial months are handled at the start and end of the contract.
• Rounding logic:  define how rounding differences are handled. Usually differences are assigned to the last period.
• Error handling and fallback behaviour: define system behaviour when schedule cannot be created.

Real world complexity

Our example is quite simple and straightforward to implement. But real implementation quickly introduces additional scenarios, including:

• Mid-contract changes like additions of services, price adjustments, or credit memos
• Pre-billing scenarios where invoicing occurs before the billing period starts
• Early termination where contracts end earlier then planned

These scenarios directly impact the revenue recognition schedule and must be properly handled in Event 2615. In practice, this is where most implementation effort sits. It is far better to capture these during design than to discover them during build or testing.

 

2. 4 Processing (FPDR)

When the schedule is created, the revenue transfer is executed by transaction FPDR. This is typically scheduled as a batch job. The program reads entries from FKKDEFREV, selects based on date and posts accounting entries (FI-CA Documents).

  Figure 6 Mass Activity – Deferred Revenue Processing    

 FPDR does not recalculate anything, it simply reads and executes the schedule generated in event 2615.

 

2.5 Accounting View

For the 12-month subscription example, the postings look like this:

 1. Invoice Posting

Dr Receivables – 1,200 / Cr Revenue 1,200

Full amount billed and recognised at invoice posting.

2. Deferral Revenue Posting

Dr Revenue 1,100 / Cr Deferred Revenue 1,100

Unearned portion reclassified to the balance sheet. USD 100 is retained as April's earned revenue.

3. Monthly Recognition (recurring)

Dr Deferred Revenue 100 / Cr Revenue 100

USD 100 released to P&L each month for the remaining 11 periods.

 

  Figure 7 Deferred Revenue Processing   – Accounting View

 

3. Conclusion

Convergent Invoicing time-based deferred revenue is an efficient capability for handling revenue recognition in subscription-driven, high-volume environments where recognition schedules are predictable.

It provides separation of earned and unearned revenue, and automates recognition over time without the complexity of a full SAP RAR implementation.

Final takeaway

CI deferred revenue does not calculate revenue recognition. Rather it executes a predefined schedule created during invoicing.

It should not be positioned as a simplified alternative to SAP RAR, but as a separate FI-CA accounting capability for a time-based revenue deferral. It is simply a different accounting mechanism.

Where revenue is strictly time-based and there is no need for performance obligation-based allocation, FI-CA deferred revenue is often an appropriate design choice in SAP BRIM.

 

Disclaimer: This article is for informational purposes only and does not represent official SAP guidance. The examples and approaches are simplified to illustrate possible technical implementation. This is not a complete solution for production use. Do not apply any solution in a production system without fully testing and confirming it in a non-production environment.