RMCS Satisfaction Status Derivation.

Problem Statement:

1.1 Ambiguity between Dual Status Fields

Within Oracle RMCS, there are two distinct status indicators that govern the revenue lifecycle: Satisfaction Status and Satisfaction Status of Additional Event (ASE). There is currently no formal documentation clarifying how these two fields interact.

1.2 Dynamic Nature of Status Derivation

Technical analysis suggests that the Performance Obligation Satisfaction Status is not static value stored in a single database column (such as LINE_SATISFACTION_STATUS in the VRM_PERF_OBLIGATION_LINES table). Instead, Oracle RMCS dynamically derives this status at runtime based on the 3 data points below:

Oracle RMCS uses three key data points:

• First Satisfaction Event Date
  The earliest date at which something that contributes to satisfaction started.
• Line Satisfaction Date
  The date at which all required satisfaction events for a POB are completed.
• Line Satisfaction Status
  A system indicator such as ORA_FULLY_SATISFIED or ORA_NOT_SATISFIED.

These are compared to the reporting date (typically SYSDATE or period end date) to determine the status.

Because this status is dynamic on RMCS UI side, custom reports must reflect the “True Status” of a contract by following similar dynamic status derivation to avoid discrepancies in revenue forecasting.

1.3 Lack of Unified Revenue Satisfaction Framework

Standard Oracle RMCS logic separates Satisfaction Status (physical/time performance) from Additional Satisfaction Event (ASE) Status (administrative/compliance holds). This separation often creates “Release Exceptions,” where revenue appears earned but remains legally trapped. Without a unified view, the Revenue Team faces:

• Manual Reconciliation: High effort required to cross-reference multiple fields during month-end close.
• Forecasting Inaccuracy: Difficulty in automating hardware revenue projections based on fragmented fulfillment data.
• Audit Risks: Lack of a documented “Source of Truth” for why specific revenue is deferred or blocked.

Solution Objectives:

• Ensure UI Alignment: Align all custom reports with RMCS UI logic to maintain data consistency and eliminate ambiguity between report outputs and the system of record.
• Implement Dual-Status Reporting: Reflect the RMCS design by including two distinct fields—Satisfaction Status and Satisfaction Status of Additional Event—ensuring that values and meanings remain identical to the RMCS UI for easier validation and comparison.
• Standardize Derivation Logic: Formally document the derivation logic for both status fields to serve as a technical blueprint for developers and a training resource for business users.
• Improve Fulfillment Visibility: Enable clearer revenue analysis by distinguishing between physical/time-based fulfillment (Satisfaction Status) and administrative/manual releases (ASE Status).
• Unified Revenue Satisfaction Framework: The goal of this initiative is to eliminate reporting ambiguity within the Forescout Revenue Management (RMCS) ecosystem by establishing a Unified Net Revenue Status. This framework aligns custom report logic with the Oracle RMCS UI while providing a single, actionable status that bridges the gap between physical fulfillment and accounting compliance.

The “Net Revenue Status” This design introduces a calculated Net Revenue Status field. By evaluating the ASE Requirement Flag and aggregating both the POB and ASE statuses, the system provides one of four clear business verdicts:

• DEFERRED: Fulfillment has not yet commenced.
• RECOGNIZING: The “gate” is open, and revenue is flowing incrementally.
• RECOGNIZED: Performance and compliance are 100% complete.
• PENDING: Physical fulfillment is complete, but a “Compliance Hold” is preventing recognition.
• PENDING (Partial): Delivery is done, but ASE only allows partial recognition.

Why we should have both Satisfaction Status and Satisfaction Status of Additional Event in the custom report.

• Satisfaction Status: Answers “The Performance Aspect” of a given performance obligation such as “Has the physical work been delivered or has the service time elapsed?” Meaning it helps track the physical fulfillment of the contract.
• Satisfaction Status of Additional Event: Answers the “Permission/Compliance Aspect” for a given performance obligation such as “Is the revenue legally or administratively allowed to be released?” It acts as a gatekeeper or a “hold” that ensures compliance.

How to derive Satisfaction Status for a given performance obligation.

In Oracle RMCS, the POB line satisfaction status is system driven and not actual revenue satisfaction indicator. The system automatically sets the satisfaction status to ‘Fully Satisfied’ once satisfaction events are created and the contract is processed through freeze and revenue recognition ESS jobs. This can occur even when Additional Satisfaction Events exist and revenue continues to be recognized over time.

Oracle RMCS evaluates satisfaction status by comparing key dates and system states at runtime. The Satisfaction Status of a Performance Obligation (POB) indicates whether revenue recognition has not started, is in progress, or is complete, based on the timing of satisfaction events relative to the current reporting date (system date).

The status must be derived using:

1. First Satisfaction Event Date
   The earliest date at which something that contributes to satisfaction started.
2. Line Satisfaction Date
   The date at which all required satisfaction events for a POB are completed.
3. Line Satisfaction Status
   A system indicator such as ORA_FULLY_SATISFIED or ORA_NOT_SATISFIED.

These are compared to the reporting date (typically SYSDATE or period end date) to determine the status.

Satisfaction Status Definitions and Business Rules

1. Extent Satisfied (Satisfaction In Progress)

Business Meaning
The performance obligation has started satisfying, but is not yet fully satisfied as of the reporting date.

Functional Conditions

• Satisfaction has begun (first satisfaction event date is on or before today)
• Final satisfaction date is in the future
• The system considers the POB to be progressing toward full satisfaction

Rule

If the first satisfaction event has occurred, but the line satisfaction date is after the reporting date, the POB is considered partially / in-progress satisfied.

Resulting Status

• Extent Satisfied

2. Not Started (Satisfaction Has Not Begun)

This status can occur under multiple business scenarios.

2a. Satisfaction Planned but Not Started

Business Meaning
The POB is defined and planned, but no satisfaction has occurred yet, even though the contract is active.

Functional Conditions

• First satisfaction event date is on or before today
• Line satisfaction date is NULL
• Line satisfaction status indicates not satisfied

Resulting Status

• Not Started

2b. No Satisfaction Events Exist

Business Meaning
The POB has no satisfaction activity defined or triggered.

Functional Conditions

• Line satisfaction date is NULL
• Line satisfaction status indicates not satisfied

Resulting Status

• Not Started

2c. Satisfaction Events Exist but Are Future-Dated

Business Meaning
The POB has satisfaction events configured, but all satisfaction activity is scheduled for the future.

Functional Conditions

• Line satisfaction date is after today
• Line satisfaction status indicates fully satisfied (future-dated configuration)

Resulting Status

• Not Started

3. Fully Satisfied (Satisfaction Completed)

Business Meaning
The performance obligation has been fully satisfied, and revenue recognition for this obligation is complete as of the reporting date.

Functional Conditions

• Line satisfaction date is on or before today
• Line satisfaction status indicates fully satisfied

Rule

If the final satisfaction event has occurred on or before the reporting date, the POB is considered fully satisfied.

Resulting Status

• Fully Satisfied

Simplified Business Decision Matrix

First Satisfaction Event	Line Satisfaction Date	Line Satisfaction Status	Satisfaction Status
≤ Today	> Today	Fully Satisfied	Extent Satisfied
≤ Today	NULL	Not Satisfied	Not Started
NULL	NULL	Not Satisfied	Not Started
> Today	> Today	Fully Satisfied	Not Started
≤ Today	≤ Today	Fully Satisfied	Fully Satisfied

A Simple Conceptual Map

To make this even easier to remember, here’s the functional mental model:

Situation	Satisfaction Status
No events yet	Not Started
Future-dated events only	Not Started
First event occurred; final event not yet	Extent Satisfied
Final event occurred	Fully Satisfied

This model is evaluated period by period and is dynamic — meaning the same POB can change status over time as events unfold.

Why This Matters for ASC 606 Compliance

Under ASC 606 and IFRS 15, revenue is recognized when performance obligations are satisfied — not when contracts are signed, billed, or paid. Oracle RMCS’s approach aligns directly with this requirement because:

• It bases status on control transfer via events, not static indicators
• It forces recognition timing to evolve with performance reality
• It ties performance status to the reporting date, which is what auditors and regulators focus on

In other words, RMCS doesn’t just store satisfaction — it evaluates it.

How to derive Net Revenue Status for a given performance obligation.

1 The Requirement for a “Net Revenue Status” Field

1.1 The Ambiguity of Disconnected Statuses

In the standard Oracle RMCS architecture, Satisfaction Status and Satisfaction Status of Additional Event (ASE) exist as independent data points. While technically accurate, these fields often provide a fragmented view of the contract’s financial health. For the Revenue Team, seeing a status of “Fully Satisfied” on a POB is misleading if an unreleased ASE hold is simultaneously preventing all revenue recognition. This disconnect forces users to manually cross-reference multiple columns to understand the true accounting position.

1.2 Inefficiency in Period-End Reconciliation

During month-end close, the Revenue Team must identify “Release Exceptions”—contracts where physical fulfillment is complete but revenue remains trapped in a liability account. Relying on two separate status fields requires complex filtering and manual work. Without a single, unified status that aggregates these conditions, the time required to diagnose recognition delays increases, extending the close cycle and increasing the risk of reporting errors.

1.3 Lack of Clear “Actionable” Data for Forecasting

For Hardware (Quantity-based) items, the decision to “Forecast” revenue into a future period is dependent on the net result of both fulfillment and compliance.

• A POB that is “Partially Satisfied” but “ASE Blocked” requires a different business action than a POB that is “Partially Satisfied” and “ASE Released.”
• Standard system statuses do not provide a “Net” value that a reporting engine can use to automatically trigger forecasting logic (e.g., projecting revenue to Book Date + 30 days).

1.4 Complexity of the “Not Required” Logic

Oracle RMCS does not require an ASE for every Performance Obligation. When a POB does not require an ASE, the ASE status field is essentially irrelevant. However, in a standard report, this creates “noise.” A business user must first check the Requirement_Flag, then check the Satisfaction_Status, and then ignore the ASE_Status. This multi-step mental process is prone to human error.

Master Logic: Net Revenue Status Determination

This master table combines the ASE Required Flag, the POB Satisfaction Status, and the ASE Status into a single, unified Net Revenue Status.

ASE Required?	POB Satisfaction Status	ASE Status	Net Revenue Status	Business Meaning / Action
N	Not Started	Not required	DEFERRED	Fulfillment hasn’t started. No ASE required.
N	Extent Satisfied	Not required	RECOGNIZING	Incremental fulfillment is occurring.
N	Fully Satisfied	Not required	RECOGNIZED	Performance is 100% complete.
Y	Not Started	Not satisfied	DEFERRED	Waiting for both delivery and the ASE trigger.
Y	Not Started	Partially satisfied	DEFERRED	Both fulfillment and compliance are pending.
Y	Not Started	Fully satisfied	DEFERRED	Compliance met, but waiting for fulfillment/start date.
Y	Extent Satisfied	Not satisfied	PENDING	Performance has started, but ASE is a total “Gatekeeper.”
Y	Extent Satisfied	Partially satisfied	RECOGNIZING	Both delivery and the ASE are moving incrementally.
Y	Extent Satisfied	Fully satisfied	RECOGNIZING	ASE gate is 100% open; status follows physical progress.
Y	Fully Satisfied	Not satisfied	PENDING	Release Exception: Delivery is done, but ASE is holding revenue.
Y	Fully Satisfied	Partially satisfied	PENDING (Partial)	Delivery is done, but ASE only allows partial recognition.
Y	Fully Satisfied	Fully satisfied	RECOGNIZED	Both Performance and Compliance are 100% complete.