Performance vs. Permission: Demystifying RMCS Satisfaction Statuses

In the world of Revenue Management (RMCS), few topics cause more confusion for implementation consultants and revenue teams than the distinction between Satisfaction Status and Satisfaction Status of Additional Event (ASE).

At a glance, having two “Satisfaction” fields feels redundant. However, understanding the interplay between them is the key to mastering revenue recognition logic, avoiding audit risks, and building accurate forecasting reports.

The Fundamental Difference: Engine vs. Handbrake

To understand these statuses, it helps to view revenue recognition as a two-stage gate:

1. Satisfaction Status (The Performance Aspect): This answers the question, “Has the physical work been delivered or has the service time elapsed?” It tracks the physical fulfillment of the contract.
2. Satisfaction Status of Additional Event (The Permission or Compliance Aspect): This answers the question, “Is the revenue legally or administratively allowed to be released?” It acts as a gatekeeper or a “hold” that ensures compliance.

The Analogy: Think of Satisfaction Status as the engine of a car and the ASE Status as the handbrake. The engine can be running (Performance is done), but the car won’t move (Revenue won’t recognize) if the handbrake is still pulled.

Comparison: Satisfaction vs. ASE Status

Feature	Satisfaction Status (POB Level)	ASE Status (Additional Event)
Logic Basis	Fulfillment (Qty, Time, or %)	Events (Manual Holds, Activation, Sign-off)
Standard Rule	Driven by Measurement Models	Driven by Satisfaction Templates/Rules
Business View	“Is the customer using the product/service?”	“Have all accounting conditions been met?”
Role	The primary trigger for revenue.	The secondary “Gatekeeper” or “Hold.”

How Logic Works Across Models

The “Performance” aspect is driven by your Measurement Model, while the “Permission” aspect is driven by your Satisfaction Template configuration.

1. Quantity-Based (Hardware)

• Scenario: 10 Laptops are ordered and shipped. The contract requires a “Customer Acceptance” sign-off before revenue can be recognized.
• Measurement Model: QUANTITY SATISFIED
• Satisfaction Status: FULLY SATISFIED (Because 10/10 units were shipped).
• ASE Status: NOT SATISFIED (Because the Customer Acceptance event hasn’t been uploaded).
• Result: Revenue stays in Contract Liability despite the hardware being with the customer.

2. Period-Based: Daily Rate (SaaS/Service)

• Scenario: A 12-month subscription. A “Manual Finance Hold” was placed on the contract to review the credit terms.
• Measurement Model: PERIOD SATISFIED
• Satisfaction Status: PARTIALLY SATISFIED (Assuming 3 months of time has passed).
• ASE Status: NOT SATISFIED (The Manual Hold is still active).
• Result: Even though 3 months of service have been “earned” based on time, zero revenue is recognized because the ASE hold is blocking the accounting.

3. Period-Based: Immediate (Software License)

• Scenario: A license key is emailed to the customer. A “Proof of Delivery” (POD) event is required to release revenue.
• Measurement Model: PERIOD SATISFIED (Plan: Immediate)
• Satisfaction Status: FULLY SATISFIED (Moves to Full on day one).
• ASE Status: NOT SATISFIED (The POD event hasn’t been imported).
• Result: Revenue remains deferred. Once the POD (ASE) is uploaded, the full 100% of revenue hits the ledger instantly.

4. Percentage-Based (Professional Services)

• Scenario: A project is 50% complete. The contract has a “Management Review Hold” (ASE).
• Measurement Model: PERCENT SATISFIED
• Satisfaction Status: PARTIALLY SATISFIED (50% Milestone achieved).
• ASE Status: NOT SATISFIED (Management hasn’t released the hold).
• Result: No revenue recognized. The 50% “Performance” is recorded, but the ASE “Permission” is missing.

Key Takeaway for Your Team

If a user asks, “Why hasn’t my revenue been recognized?”, they should check in this order:

1. Check Satisfaction Status: If it is “Not Satisfied,” the delivery hasn’t happened.
2. Check ASE Status: If Satisfaction is “Full” but Revenue is $0, there is an ASE Hold blocking it.

The Troubleshooting Guide: What the Status Combinations Mean

When your reports show $0 revenue where you expected a value, use this matrix to diagnose the “Net Revenue Status.”

POB Satisfaction Status	ASE Status	Net Revenue Accounting Status	Business Meaning & Required Action
Not Satisfied	Not Satisfied	Deferred ($0 Recognized)	Meaning: Fulfillment hasn’t started and no release event has occurred. Action: Verify if the item has shipped (Qty) or if the service date has passed (Period).
Fully Satisfied	Not Satisfied	Deferred ($0 Recognized)	Meaning: “Release Exception.” Fulfillment is complete, but an accounting “Hold” (ASE) is blocking recognition. Action: Identify the specific ASE (e.g., Manual Hold or Proof of Delivery) and upload/release the event.
Partially Satisfied	Fully Satisfied	Recognizing (Incremental)	Meaning: The accounting “gate” is open, and revenue is flowing based on delivery/time. Action: None required. This is normal for over-time services or partial shipments.
Fully Satisfied	Fully Satisfied	Recognized (100%)	Meaning: Performance and Permission are both complete. Action: Reconciliation complete for this POB.
Partially Satisfied	Not Satisfied	Deferred ($0 Recognized)	Meaning: Some work is done, but the ASE is blocking all revenue. Action: Revenue will not “trickle in” until the ASE is released, even if the POB is partially satisfied.

Specific Examples with Solution post Troubleshooting

Scenario A: The “Stuck” Hardware Shipment (Quantity Model)

• Data: 5 Units Shipped out of 5 Ordered.
• POB Satisfaction Status: FULLY_SATISFIED
• ASE Status: NOT_SATISFIED (Reason: Customer Acceptance required)
• Why it’s confusing: The warehouse says it’s done, but the General Ledger shows $0 revenue.
• Solution: The user must import the “Customer Acceptance” event to move ASE to FULLY_SATISFIED.

Scenario B: The “Locked” Subscription (Period Model)

• Data: 12-month contract, now in month 6.
• POB Satisfaction Status: PARTIALLY_SATISFIED
• ASE Status: NOT_SATISFIED (Reason: Manual Finance Hold)
• Why it’s confusing: The service is being provided, but no revenue is hitting the monthly waterfall.
• Solution: Finance must manually release the Satisfaction Hold in the RMCS UI to “catch up” the 6 months of revenue.

Scenario C: Hardware “Not Required”

• Data: Simple Hardware shipment with no extra compliance steps.
• POB Satisfaction Status: FULLY_SATISFIED
• ASE Status: NOT_REQUIRED
• Why it’s confusing: New users may look for a “Full” status in the ASE column.
• Solution: In your report, treat NOT_REQUIRED as a “Green Light.” If ASE is NOT_REQUIRED, the POB Satisfaction Status is the only trigger that matters.

Technical Insight: Is an ASE Even Required?

A critical step in revenue reporting is identifying if an ASE is even mandated for a POB.

You cannot accurately report on the Additional Satisfaction Event (ASE) without first determining if one is even mandated for that specific Performance Obligation (POB).

If you skip this step, your report might falsely show a “Missing Event” for a POB that never required one in the first place.

Step 1: Determining if an ASE is Required

An ASE is required only if the POB is associated with a Satisfaction Template where the “Additional Satisfaction Event” attribute is enabled.

The “Net Revenue Status” Derivation Logic

Once you know if an ASE is required, you can combine the two statuses into a single “Net Revenue Status”. This is the field that the Revenue Team will actually use to drive their Waterfall and Forecast reports.

Logic Flow (Plain Text for FSD/SDD)

Rule 1: If ASE is NOT Required

Net Revenue Status = Same as POB Satisfaction Status.

Meaning: If fulfillment is done, revenue is recognized.

Rule 2: If ASE IS Required  

Use the following matrix to determine the Net Status:

POB Satisfaction Status	ASE Status	Net Revenue Status
Fully Satisfied	Fully Satisfied	RECOGNIZED
Fully Satisfied	Not Satisfied	BLOCKED (Pending Event)
Partially Satisfied	Not Satisfied	BLOCKED (Pending Event)
Not Satisfied	Not Satisfied	DEFERRED (Pending Delivery)

If you find yourself asking, “Why hasn’t my revenue recognized?”, follow this order of operations:

1. Check Fulfillment: Has the item shipped or has the start date passed? (Check Satisfaction Status).
2. Check Compliance: Is there a “Satisfaction Hold” or a missing “Proof of Delivery” event? (Check ASE Status).

By surfacing both of these fields in your custom reports, you move from simple data viewing to proactive revenue management, ensuring you can identify and resolve “Release Exceptions” before month-end close.

Summary:

To simplify the “Why is there an ASE?”:

1. Measurement Model (Quantity/Period/Percent): Measures the PHYSICAL progress of the deal.
2. ASE Requirement Flag: Measures the COMPLIANCE requirement of the deal.

Why do we have both? Because company might ship a hardware product (Physical = Done) but legally cannot recognize revenue until the customer signs an Acceptance Form (Compliance = Pending). Without the ASE, RMCS would recognize the revenue too early, leading to an audit failure.