SAP RAR (Revenue Accounting and Reporting)

for IFRS 15

Implementation Methodology, Performance Obligations, and

Contract Modifications

1. Why RAR Exists: IFRS 15's Five-Step Model

IFRS 15 (converged with US GAAP ASC 606) replaced the older "risk and rewards transfer" revenue
model with a five-step framework that fundamentally decouples when you invoice from when you
recognize revenue:

1. Identify the contract with a customer

2. Identify the performance obligations in the contract
3. Determine the transaction price
4. Allocate the transaction price to each performance obligation
(based on relative standalone selling price)
5. Recognize revenue as each performance obligation is satisfied
(over time, or at a point in time)

The practical problem this creates: a standard SD billing document reflects what you're invoicing the
customer, not necessarily what you're entitled to recognize as revenue under this model. A bundled
contract — hardware plus installation plus a year of support, sold as one deal at one combined price —
needs that combined price split across three distinct performance obligations, each recognized on its own
pattern (installation at a point in time, support ratably over the year), regardless of how the invoice itself
is structured. Standard SD billing has no native concept of "performance obligation" or "standalone
selling price allocation" — this is exactly the gap SAP RAR exists to fill, sitting as a dedicated sub-ledger
between the operational SD/billing layer and the FI general ledger.
2. SAP RAR Architecture Overview

2.1 Core objects

Object What it represents

Revenue The raw inbound record — a snapshot of relevant data from an SD sales order item,
Accounting Item contract, or billing document, sent into RAR for processing
(RAI)

Performance RAR's central object — the distinct promise to transfer a good or service, which may
Obligation (POB) not map 1:1 to an SD order item (one order item can split into multiple POBs; several
order items can combine into one)

Contract (in RAR's The grouping of POBs that together make up the accounting contract with the
sense) customer — not necessarily the same boundary as a single SD sales document

Contract Asset Unbilled receivable — revenue recognized exceeds amount invoiced so far

Contract Liability Deferred revenue — amount invoiced exceeds revenue recognized so far
2.2 The data flow, end to end

SD sales order / contract (VBAK/VBAP)

↓
Revenue Accounting Item (RAI) generated
— an integration component reads relevant SD fields and creates
an RAI record; this is the inbound interface into RAR
↓
BRFplus-driven mapping determines how RAIs combine into
Performance Obligations
— this is where "is this one PO or three?" gets decided,
based on rules configured against the business's actual
contract structures, not a fixed 1:1 assumption
↓
Standalone Selling Price (SSP) determined and transaction price
allocated across the POBs in the contract
↓
Fulfillment events recorded against each POB as it's satisfied
— goods issue, time elapsed, milestone achieved, or
percentage-of-completion measure, depending on POB type
↓
Revenue recognized incrementally as fulfillment progresses
↓
RAR posts to FI — recognized revenue, and the resulting
contract asset or contract liability position — reconciled
against, but posted separately from, the SD billing document's
own FI postings

The critical architectural point: RAR doesn't replace SD billing, it runs alongside it. Billing still
happens through normal SD processes; RAR's job is purely to determine what revenue is recognizable,
independent of the invoice timing, and to post that recognition to its own contract asset/liability
accounts, which then reconcile against (but aren't identical to) the AR/revenue postings billing itself
generates.

3. Implementation Methodology
A RAR implementation is as much an accounting design exercise as a technical configuration one —
arguably more so. The phases:

Phase 1 — Performance obligation identification workshops. Working directly with technical

accounting/controllership (not just the SD/IT team) to define what constitutes a "distinct" performance
obligation for each of the business's actual contract types. This is a judgment call under IFRS 15's own
criteria (is the good/service separately identifiable, and can the customer benefit from it either on its own
or combined with readily available resources?) — it has to be resolved as an accounting policy decision
before any BRFplus rule can be written to implement it.

Phase 2 — Standalone Selling Price methodology design. For every product/service line, finance
needs to define how SSP will be determined — see Section 5. This, too, is an accounting judgment
exercise before it's a configuration exercise, particularly for anything that's never actually sold on a
standalone basis.

Phase 3 — BRFplus rule configuration. Translating the Phase 1 decisions into the actual rules that
determine RAI-to-POB mapping.

Phase 4 — Fulfillment/recognition method configuration per POB type. Point-in-time vs.

over-time, and for over-time, which specific method (straight-line, percentage-of-completion, output-
based milestones) applies to which POB category.

Phase 5 — Account determination configuration. Contract asset and contract liability GL

accounts, mapped consistently with how the business's chart of accounts already models deferred
revenue and unbilled receivables, but now driven by RAR's own posting logic rather than manual journal
entries.

Phase 6 — Contract modification logic configuration and testing. Covered in depth in Section 7
— this is consistently the hardest and most heavily tested part of a RAR implementation.

Phase 7 — Parallel run and reconciliation. Many organizations implementing RAR are moving
from an Excel-based (or heavily manual) IFRS 15 calculation process. The parallel run compares RAR's
calculated recognition against the legacy manual process, line by line, until the two converge within an
accepted tolerance — this is where most of the genuine implementation risk surfaces, because it's where
accounting judgment mismatches between "how we've been doing it manually" and "how the configured
rules actually behave" become visible.

Phase 8 — Cutover and historical contract migration. The genuinely hard part — see Section 9.

Phase 9 — Disclosure reporting. RAR's data model is built to directly support the IFRS 15 disclosure
requirements (disaggregated revenue, contract balance roll-forwards, remaining performance obligation
disclosures) — this should be validated against actual disclosure note requirements during testing, not
left until the first real reporting cycle.

4. Performance Obligation Identification and Configuration

4.1 The BRFplus mapping layer

BRFplus (Business Rule Framework plus) is the decision-table engine that determines how
inbound Revenue Accounting Items combine into Performance Obligations. This is deliberately built as
configurable business rules rather than hardcoded logic, because "what counts as one performance
obligation" varies enormously by industry and even by product line within the same company — a
software company's SaaS-plus-implementation-plus-support bundle looks nothing like a machinery
manufacturer's equipment-plus-installation-plus-warranty bundle, and both need different combination
rules.

Example BRFplus decision logic (conceptual):

IF SD item category = "Software License"

AND SD item category = "Implementation Services" (same contract)
AND implementation is NOT sold separately at comparable pricing
THEN combine into ONE performance obligation
(implementation is not distinct — it significantly modifies
the license and isn't separately identifiable)

IF SD item category = "Hardware"

AND SD item category = "Extended Warranty" (same contract)
AND warranty IS regularly sold on a standalone basis
THEN treat as TWO separate performance obligations
(each is distinct and separately identifiable)

4.2 Why this can't be a fixed 1:1 mapping

The reason a flexible rules engine is necessary rather than a simple "one SD item = one POB" default: real
contracts routinely need the opposite mapping in both directions — several SD line items that together
form one non-distinct performance obligation (a customized, highly integrated solution where the pieces
can't be separately valued), and single SD line items that need to be split into multiple performance
obligations (one line item representing a bundled price for a good plus an embedded service
commitment). Getting Phase 1's accounting judgment translated correctly into Phase 3's BRFplus rules is
the single most consequential design decision in the whole implementation — it drives every downstream
number.

5. Standalone Selling Price (SSP) Determination

SSP is the price at which a good or service would be sold separately — it's what the transaction price gets
allocated across performance obligations in proportion to, not the invoice price for that specific line.
5.1 Determination methods
Method When used

Observable price The good/service genuinely is sold standalone at a consistent price — use that directly

Adjusted market Estimate what a similar good/service sells for in the relevant market, adjusted for the
assessment company's specific costs and margins

Expected cost Estimate the expected cost of satisfying the obligation and add an appropriate margin —
plus margin common for items that are never sold standalone (an embedded warranty, for instance)

Residual Only permitted in narrow circumstances (highly variable or uncertain pricing for one
approach item in the bundle) — allocate the residual of the total transaction price after allocating
observable SSPs to everything else

5.2 Configuration in RAR

SSP is maintained as reference pricing data RAR consults during the allocation step — conceptually
similar to maintaining a price list, but explicitly separate from the actual selling price on any given
contract. When a contract bundles multiple POBs at a combined price, RAR:

1. Determines SSP for each POB (from maintained reference data,

or a BAdI-based custom determination for cases too complex for
simple reference pricing)
2. Calculates each POB's proportional share of total SSP
3. Allocates the actual transaction price across POBs in that
same proportion
(this is why the allocated amount for any single POB can differ
from what that item might individually cost on an invoice — the
allocation follows relative SSP, not the invoice line amount)

This is also precisely where contract modifications (Section 7) get complicated — adding or changing a
POB mid-contract means re-running some or all of this allocation, and the correct treatment depends on
which modification category applies.

6. Fulfillment and Revenue Recognition Methods

Once a POB exists with an allocated transaction price, revenue recognizes as fulfillment progresses — but
how fulfillment is measured depends on the POB's classification:

Point in time. Revenue recognizes fully when control transfers — typically triggered by a goods issue
event flowing from the SD delivery, or another discrete triggering event. Appropriate for most
straightforward goods sales.
Over time — straight-line. Revenue recognizes evenly across the service period — the standard
pattern for a support/maintenance contract or a subscription. RAR calculates a per-period recognition
amount and posts it on a systematic schedule tied to the contract's duration.

Over time — percentage of completion (POC). For long-term contracts (construction, large
implementation projects) where progress is measured by costs incurred relative to total expected costs,
or by another input/output measure of progress — this typically integrates with Project Systems (PS) or a
comparable cost-tracking source to feed the actual progress measure into RAR's recognition calculation.

Over time — milestone/output-based. Revenue recognizes as specific, contractually defined

milestones are achieved (a specific project phase completed, a specific deliverable accepted) rather than
on a time or cost basis.

The choice of method isn't a technical preference — it's dictated by which pattern IFRS 15 says best
depicts the transfer of control for that specific POB, which is another Phase 1 accounting judgment that
gets configured, not decided in the configuration itself.

7. Contract Modifications — The Three IFRS 15 Treatments

This is consistently the most technically demanding part of a RAR implementation, because IFRS 15
defines three genuinely different accounting treatments for a contract modification, and the correct one
depends on facts and circumstances that have to be evaluated at the point of modification, not decided
generically in advance.

7.1 Treatment 1 — Separate contract

When it applies: the modification adds distinct goods/services, priced at their standalone selling price.

Accounting effect: the modification is treated as an entirely new, separate contract. The original
contract's existing POBs and recognized revenue are completely unaffected.

RAR handling: the new goods/services generate new RAIs that map to new POBs in what RAR treats as
a distinct contract — no adjustment flows back to the original contract's POBs at all.

7.2 Treatment 2 — Prospective (termination of old + creation of new)

When it applies: the added goods/services are not priced at standalone selling price, but the remaining
goods/services in the original contract are still distinct from what's already been transferred.

Accounting effect: treated as if the original contract terminated and a new contract was created
covering the remaining original performance obligations plus the newly added ones. The remaining
(unallocated) portion of the original transaction price, plus the new consideration from the modification,
gets reallocated across the remaining and new POBs — but prospectively only. Revenue already
recognized on POBs already satisfied is not touched.
RAR handling: the modification triggers a re-allocation of remaining transaction price across the still-
open POBs plus any new ones, using SSP at the time of modification — but this is scoped only to what
hasn't yet been recognized. This is the treatment that most directly exercises the SSP allocation logic in
Section 5, run a second time against a changed POB set.

7.3 Treatment 3 — Cumulative catch-up

When it applies: the remaining goods/services are not distinct from those already transferred — most
commonly, a single, non-distinct performance obligation being satisfied over time (a long-term
construction or POC contract) where the modification changes the scope or price of that same ongoing
obligation.

Accounting effect: treated as if the modification had been part of the original contract from the start.
This requires a cumulative catch-up adjustment — revenue recognized to date gets recalculated as if
the modified terms had always applied, and the difference between what was already recognized and
what should have been recognized under the new terms posts immediately as a true-up, rather than being
spread prospectively.

RAR handling: this is the most complex of the three to configure and test correctly, because it requires
RAR to recalculate the POB's recognized-to-date position under the new terms and post the delta as an
immediate adjustment — effectively re-running the recognition calculation retroactively for the affected
POB, then reconciling that against what was actually already posted to FI in prior periods.

7.4 Configuration approach

Contract modification determination is itself typically driven by

BRFplus rules (or a custom BAdI for genuinely complex cases),
evaluating at minimum:

- Is the added scope priced at standalone selling price?

→ if yes, and distinct → Separate contract
- Are the remaining, not-yet-satisfied POBs distinct from
what's already been delivered?
→ if yes → Prospective treatment
→ if no (single non-distinct obligation, POC scenario) →
Cumulative catch-up

This determination should not be left to be decided ad hoc by

whoever processes the modification — it needs to be a configured,
consistent rule set reviewed by technical accounting, precisely
because getting the wrong one of the three treatments applied
produces a materially wrong revenue number, not just a
timing difference.
7.5 Why this is the hardest part to test
Unlike initial contract setup (which can be validated against a stable set of test contracts), modification
testing needs to cover the cross-product of modification type × POB recognition method × timing of
modification relative to the POB's fulfillment progress. A prospective modification hitting a straight-line
POB behaves differently from a cumulative catch-up hitting a POC-based POB, and both need distinct
test scenarios — this is where implementation timelines most often slip, because the test matrix is
genuinely larger than it initially looks.

8. Account Determination and FI Reconciliation

RAR posts to its own contract asset and contract liability accounts — separate from, but reconcilable
against, the AR and revenue accounts SD billing posts to directly. The reconciliation that has to balance,
ongoing, for every contract:

Amount invoiced (SD billing, posted to AR/Revenue)

vs.
Amount recognized (RAR, posted to Contract Asset/Liability)

If recognized > invoiced → Contract Asset (unbilled receivable)

If invoiced > recognized → Contract Liability (deferred revenue)
If recognized = invoiced → no contract asset/liability balance

Account determination configuration needs to map POB type, product/service classification, and
company code consistently to the correct contract asset/liability GL accounts — and this mapping needs
to align with how the business's chart of accounts and existing deferred-revenue reporting already works,
since RAR is typically replacing a manual or semi-manual process the finance team has been reconciling
against for years.

9. Migration and Cutover for In-Flight Contracts

This is the part of a RAR implementation that most often gets underestimated in planning. On go-live,
the business doesn't get to start with a clean slate — every multi-year contract already in progress has
some combination of: performance obligations already fully satisfied, POBs partially recognized under
the legacy (often manual) process, and POBs not yet started.
 Migration approach, per in-flight contract:

1. Determine, as of the cutover date, the correct POB structure

under the NEW rules (Section 4) — this may not match how the
contract was actually being tracked under the legacy process
2. Determine revenue recognized to date, per POB, reconciled
against what's actually been posted to the GL historically
3. Load the contract into RAR with:
- Historical recognized-to-date amount (so RAR doesn't
re-recognize revenue that's already been booked)
- Remaining transaction price and remaining POB fulfillment
status, so future recognition proceeds correctly from here
4. Reconcile the migrated contract's asset/liability position
against the legacy balance sheet position for that contract —
any variance needs investigation and resolution BEFORE go-live,
not after

The reconciliation step (4) is where most cutover effort actually goes — it's straightforward in concept but
can be substantial in volume for a business with thousands of open multi-year contracts, each needing
individual verification that the migrated starting position is correct.

10. Common Implementation Challenges

Performance obligation identification is an accounting judgment, and treating it as a pure
IT configuration exercise produces wrong results downstream no matter how well the
BRFplus rules are built. The rules can only be as correct as the underlying accounting policy decision
they implement.

SSP for never-standalone items requires genuine estimation work, and if finance hasn't
already built a defensible SSP methodology before configuration starts, the project stalls waiting for that
policy decision rather than progressing on schedule.

Contract modification logic needs a test matrix, not a handful of example scenarios — the
cross-product of modification type and recognition method is larger than it looks at first glance, and
under-testing this is the most common source of post-go-live revenue restatement risk.

Reconciliation against the legacy process during parallel run surfaces judgment
mismatches, not just bugs. When RAR's calculated recognition differs from what the manual process
produced, the first question shouldn't be "what's wrong with the configuration" — it should be "which
one is actually correct under IFRS 15," because the manual process being replaced was often itself an
approximation.
Cutover migration volume is routinely underestimated — reconciling thousands of in-flight
contracts' starting positions individually is a substantial, unglamorous effort that needs to be resourced
and scheduled as its own workstream, not treated as a footnote to the "real" configuration work.

11. Configuration and Tooling Reference

Area Where it lives

RAI inbound integration SD-to-RAR integration component, reading VBAK/VBAP and billing data

POB mapping rules BRFplus decision tables

SSP reference data RAR pricing/SSP maintenance (Fiori app)

maintenance

Contract and POB monitoring "Manage Revenue Contracts" (Fiori app)

Contract modification analysis Contract change analysis apps within the RAR Fiori catalog

Account determination RAR account determination configuration, aligned to POB type and company
code

Historical migration Dedicated RAR migration tooling for loading in-flight contract starting
positions

Summary
SAP RAR's job is to insert a genuine sub-ledger between SD billing and the general ledger specifically
because IFRS 15 requires revenue recognition to follow the pattern of performance obligation
satisfaction, not the pattern of invoicing. Performance obligation identification and standalone selling
price allocation are the two decisions that determine almost everything downstream, and both are
accounting judgments first, configuration exercises second — the BRFplus rules and SSP reference data
can only be as correct as the policy decisions they implement. Contract modifications are where the
system gets genuinely difficult, because IFRS 15's three treatments (separate contract, prospective
reallocation, cumulative catch-up) aren't interchangeable — applying the wrong one produces a
materially wrong number, not just a timing difference — and testing the full cross-product of
modification type against recognition method is usually the single most underestimated piece of the
whole implementation timeline.