# How ConEd's Delivery Adjustments Work: A Complete Explainer

> ⚠️ **Disclaimer**: This guide was generated by an LLM (Claude Opus 4.5) based on the tariff JSON plus the model's background knowledge of utility regulation and NY PSC proceedings. The content looks reasonable but **has not been verified by domain experts**. Please verify any claims before relying on them for business or regulatory purposes.

## Overview

ConEd's delivery charges aren't just a single rate—they're a **base rate plus multiple adjustments**. This guide explains what each adjustment does, why it exists, and how it's calculated.

```
Your Delivery Bill = Base Delivery Rate (Summer/Winter Rate)
                   + Delivery Revenue Surcharge
                   + Reconciliation Rate
                   + Transition Adjustment
                   + Uncollectible Bill Expense
                   + Monthly Adjustment Clause
                   + Revenue Decoupling Mechanism Adjustment
                   + Clean Energy Standard Delivery Surcharge
```

All of these adjustments have `variableRateKey` in the JSON—meaning they change periodically and require the Lookups API to get current values.

---

## The Problem Rate Cases Can't Fully Solve

The point of a rate case is to set rates in advance so that the resulting **revenue** covers **expected costs**. That means the regulator and utility have to guess two things: (1) **costs**—what will it cost to serve customers? (2) **loads**—how many kWh will be sold? Because revenue = rate × load, the rates are set so that (rate × forecast load) equals the **revenue requirement** (the authorized dollar total needed to cover forecasted costs).

Both guesses are uncertain. **Loads** might be higher or lower than expected—a mild summer or a hot one, more efficiency, more electrification—so you may **over- or under-collect** the revenue you set out to collect. Even if you hit the revenue requirement on the nose, you might have **forecasted costs wrong**: actual costs could be above or below what was baked into that revenue requirement, so the money you collect might be too much or too little relative to what costs actually were.

**RDM** (Revenue Decoupling Mechanism) addresses the first problem: it true-ups **revenue** so that, regardless of whether load was higher or lower than forecast, the utility eventually collects the revenue requirement. **MAC** (Monthly Adjustment Clause) addresses part of the second: a defined basket of costs that are volatile and hard to predict is true-upped **monthly** so that those costs are fully recovered (or refunded when over-collected) without waiting for the next rate case. The sections below explain how each works.

---

## The Adjustment Mechanisms

### 1. Revenue Decoupling Mechanism (RDM) Adjustment

Assume for the moment that the **costs** in the revenue requirement were forecast correctly. The rates are still set using an **expected** amount of load (kWh per year). Revenue = rate × actual load, so if actual load is lower than forecast, you **under-collect** the revenue requirement; if actual load is higher, you **over-collect**. At the end of the rate year, there is a deficit or surplus relative to the dollar target the PSC authorized.

**RDM** true-ups that revenue shortfall or surplus. It compares **actual delivery revenue collected** (from base rates and other adjustments in effect) to an **annual delivery revenue target**—the authorized revenue requirement for that rate year. The shortfall or overage is then collected from (or refunded to) customers in the **following** period. ConEd uses a **Revenue Per Customer (RPC)** methodology: a target $ per customer is set; the delivery revenue target for the year = RPC target × actual average number of customers. Actual revenue is compared to that target.

The RDM adjustment is a **$/kWh** rate: the dollar variance is spread over **forecasted** kWh for the period when the new rate applies (e.g. the next rate year or the period until the next reconciliation). So next year's bills include an RDM surcharge (if there was a shortfall) or credit (if there was over-collection). Because that true-up is also spread over _forecasted_ kWh, the recovery in that period can be slightly high or low; that residual is picked up in the _next_ RDM reconciliation. Over time, total delivery revenue converges to the revenue requirement.

RDM is reconciled **annually** (not monthly like MAC). The lag is typically 12–18 months: this year's RDM rate reflects last year's over- or under-collection.

#### RDM and energy efficiency

While RDM solves the general problem that sales are hard to forecast and therefore revenue often misses the target, it's often discussed as fixing the **throughput incentive**—the idea that utilities were set against energy efficiency (EE) programs because EE reduces sales and thus revenue. The connection is real, but the story is subtler.

**Before EE.** Revenue requirement = $100M (numerator), forecast sales = 1,000 GWh (denominator), so rate = $0.10/kWh. If actual sales = 1,000 GWh, the utility collects $100M and is whole.

**Add an EE program.** The commission adds the EE program to the revenue requirement: new numerator = $103M ($100M + $3M program). If the **denominator is left at 1,000 GWh** and the rate is updated to $0.103/kWh, but EE actually reduces sales to 950 GWh, the utility collects 950 × $0.103 = $97.85M. Shortfall = $5.15M. So the utility is worse off for having run EE—it both spent $3M on the program and came up short on total revenue. That's the disincentive.

**In principle, no shortfall.** The commission could instead set the **denominator** to the post-EE forecast (e.g. 950 GWh) and the rate to $103M / 950 = $0.1084/kWh. Then when sales = 950 GWh, the utility collects $103M. No shortfall. That approach—recovering revenue "lost" due to EE by building the expected sales impact into the rate (or by a separate lost-revenue adjustment)—is called a **Lost Revenue Adjustment Mechanism (LRAM)**. So in principle there is no structural problem: you can make the utility whole by adjusting for the EE-driven sales drop.

**In practice, LRAM ran into real problems.** States tried LRAM-style mechanisms in the 1980s and early 1990s. The experience was contentious: LRAM required **estimating** how much of the sales change was due to EE (evaluation, measurement, and verification—EM&V), which is disputed and costly. Recovery was usually **asymmetric**—utilities could recover when sales fell (EE) but often kept surplus when sales rose—so the throughput incentive wasn't fully removed. (In principle, truing to a revenue target would imply surcharge when below target and refund when above; LRAM was instead framed and implemented as "recover lost revenue from EE," so it had only the recovery leg and no matching refund when sales rose.) With infrequent rate cases, "lost revenue" from multiple years **pancaked**, so the bill impact was large and politically toxic. Lost-revenue recovery sometimes approached the total amount spent on efficiency. Many states abandoned the approach.

**Why RDM instead?** RDM's "make revenue match the revenue requirement" achieves the same goal—utilities don't under-recover when sales fall—but in a way that avoids what made LRAM hard. RDM uses **actual total sales**, not an estimate of how much sales changed _because of_ EE, so there's no need to attribute the change to EE (no EM&V fight over cause). The true-up is **symmetric**: if sales are above forecast, the utility refunds; if below, it surcharges. So the throughput incentive is fully removed, and the utility has no reason to oppose EE or chase sales. Adjustments are **periodic** (e.g. annual), so they don't pancake over many years the way LRAM did when rate cases were years apart. In short, RDM makes the utility indifferent to sales volume without requiring anyone to agree on or measure the share of the sales change due to EE, and without the one-sided recovery and political blowback that LRAM produced.

#### Variable Rate Key

```json
"variableRateKey": "revenueDecouplingMechanismAdjustmentSc1"
```

---

### 2. Monthly Adjustment Clause (MAC)

So RDM ensures the utility collects the **revenue requirement** regardless of load. But what if the **costs** that were baked into that revenue requirement were wrong? Some of the costs the utility actually incurs are volatile and hard to predict—property taxes, storm damage, pension and benefit costs, environmental compliance, and similar items. If those turn out higher or lower than forecast, the revenue requirement (and thus the revenue you collect with RDM in place) is no longer aligned with actual costs for that basket.

A subset of delivery costs is designated the **MAC basket**. These are PSC-approved, pass-through style costs that are true-upped **every month** (not every year) so that they are fully recovered—or any over-collection is refunded—without waiting for the next rate case. The MAC basket typically includes property tax changes, storm-related costs, pension/OPEB, environmental compliance, and other volatile pass-throughs. Because they're hard to predict, the PSC pre-approves this reconciliation mechanism.

#### What about non-MAC costs that are wrong?

Other costs in the revenue requirement (labor, wires, depreciation, non-MAC O&M, etc.) are **not** true-upped continuously like the MAC basket. If actual non-MAC costs differ from what was in the revenue requirement, the utility may under- or over-recover those costs even though RDM has made total **revenue** match the revenue requirement. Those variances are typically handled through **deferral accounts**: under-recoveries are booked as regulatory assets (to be recovered later), over-recoveries as regulatory liabilities (to be credited back later). The balances are then **amortized or reconciled in the next rate case**—the next rate case sets a new revenue requirement that can include amortization of those deferrals. So the utility (or customers) are made whole over the rate-case cycle, not every month or year.

#### How MAC works (mechanics)

ConEd's tariff applies the MAC as a single line item; the underlying **Statement of Adjustment Factor - MAC** (filed with the PSC) has three components: **MAC Reconciliation**, **Uncollectible-bill Expense**, and **Transition Adjustment**. Uncollectible Bill Expense is described in the next section; Transition Adjustment and Reconciliation Rate have their own sections below. This section describes the **MAC** as it appears on the bill—the **MAC Reconciliation** component.

**Base rate and MAC component.** In the rate case, the PSC sets the delivery revenue requirement (including an allowance for the MAC basket) and expected sales. The **base** $/kWh is a single blended rate set so that (base rate × expected sales) recovers that full requirement. For reconciliation, the portion of the base rate that corresponds to **forecasted** MAC costs is defined explicitly—e.g. (forecasted MAC costs for the year ÷ forecasted kWh for the year) in $/kWh. That slice is the "MAC component" of the base; customers don't see it as a separate line.

**Actual MAC revenue.** In any month, revenue counted as "for MAC" is: **(MAC component of base × actual kWh) + (MAC adjustment rate in effect that month × actual kWh)**.

**True-up.** Each period (e.g. prior month), ConEd compares **actual** costs for the MAC basket to **actual MAC revenue** (as defined above). **Variance** = actual costs − actual MAC revenue. If positive, the utility under-collected for MAC; if negative, it over-collected.

**MAC rate (the line item).** That variance (in dollars) is turned into a **$/kWh** rate by spreading it over **forecasted** kWh for the period when the new rate will apply (e.g. next month). So the **MAC rate** you see this month is the true-up for a **prior** period (prior month, per ConEd's description), applied to your current-month usage. Spreading over forecasted (rather than actual) kWh can still cause over- or under-collection of that true-up; any such error is absorbed into the **next** period's reconciliation. The lag is about one month.

**Dual role of MAC.** MAC does two things: (1) **Level**—when the annual forecast for MAC costs (or the load used to set the MAC component) is wrong, MAC true-ups so the utility collects the allowed amount for that basket over time. (2) **Timing**—even when the annual forecast is correct, MAC costs are lumpy (storms, tax payments) while revenue from the base follows load; month-by-month, actual cost and actual collection often don't match. MAC shifts **when** dollars are collected so they align better with **when** costs were incurred. So MAC is not "extra" revenue—it keeps recovery for the MAC basket in line with actual costs and timing.

#### Effect on monthly collection

Your delivery charge each month includes **(base + MAC) × kWh**. When the **prior** period had **under**-recovery, the current MAC rate is **positive** → you collect more this month. When the prior period had **over**-recovery, the MAC rate is **negative** (a credit). Over a full year, if the annual cost and load forecasts for the MAC basket were perfect, the **sum** of MAC collections would be close to zero—you'd just be shifting which months contribute more or less, so the utility's cash flow better matches when it actually incurred the costs.

#### Variable Rate Key

```json
"variableRateKey": "monthlyAdjustmentClauseResidential"
```

---

### 3. Uncollectible Bill Expense

When some customers don't pay their bills, the utility doesn't absorb the shortfall—**paying customers** are made whole through rates. Regulators allow this by treating expected unpaid bills as a **cost** (uncollectible or bad-debt expense) and adding it to the **revenue requirement**. Base rates are then set to collect that expected shortfall in advance. So the mechanism is an accounting choice: unpaid bills are framed as a "cost" so the utility can raise rates on everyone else to cover the amount it expects not to collect.

Actual bad debt is volatile (economic conditions, disconnection rules, arrears). If **actual** uncollectible expense is higher than the amount baked into rates, the utility under-recovers via base rates; if lower, it over-recovers. The **Uncollectible Bill Expense** line is the **true-up**: it reconciles actual vs. expected uncollectible (and in practice, per PSC filings, late payment charge revenue is often reconciled together with it). When actual > expected, the adjustment is a surcharge; when actual < expected, a credit. In this way it behaves like the other MAC components—a volatile "cost" that is trued up **monthly** instead of waiting for the next rate case.

On ConEd's **Statement of Adjustment Factor - MAC**, Uncollectible Bill Expense is one of the **three columns** (with Transition Adjustment and Reconciliation Rate). So it is a **subcomponent** of that MAC statement. On the bill and in Genability it appears as a **separate** line item with its own variable rate key. Lag is about one month, like the other MAC-statement components.

#### Variable Rate Key

```json
"variableRateKey": "macAdjustmentUncollectibeBillExpense2252"
```

---

### 4. Transition Adjustment

When New York restructured (generation separated from delivery, retail choice introduced), utilities were left with obligations that were no longer economic in a competitive market: **stranded plants** (e.g., a plant taken out of service but still on the books—regulators let them recover the remaining value through rates), **above-market power contracts** (long-term PPAs at 6¢/kWh while the market fell to 3¢—they kept paying, or bought out the contract for a lump sum and recovered that from ratepayers over time), and **one-time transition costs** (separation, buyouts, settlements). Those amounts were (and in small part still are) recovered from customers on a schedule set in rate cases: so much per year in amortization, plus interest on any balance that built up when the utility under-collected in a prior period.

In the rate case, the commission **forecasts** how much of that recovery will land in each period. In practice, the actual amount can differ: the **schedule** can slip or stretch (same total dollars, different timing); **interest** on any deferral balance depends on that balance and the formula rate, which may not match the forecast; a **remaining contract payment** or a **small settlement** might come in above or below the estimate. The **Transition Adjustment** is the **monthly true-up**: it reconciles what was actually recovered (or what was actually due) for this basket against what was built into rates, so the utility doesn't over- or under-recover. When actual &gt; expected, the adjustment is a surcharge; when actual &lt; expected, a credit.

Structurally it's the same idea as the MAC basket and Uncollectible Bill Expense: the **cost** (here, the allowed recovery of legacy transition/stranded amounts) turned out different than we thought, so we true up instead of waiting for the next rate case. On ConEd's **Statement of Adjustment Factor - MAC**, Transition Adjustment is one of the three columns (with Uncollectible and Reconciliation Rate); on the bill it's a separate line item. Lag is about one month.

#### Variable Rate Key

```json
"variableRateKey": "macAdjustmentTransitionAdjustment2252"
```

---

### 5. Reconciliation Rate

#### What It Is (from the tariff and MAC statement)

The **Reconciliation Rate** is the **third component** of ConEd's **Statement of Adjustment Factor - MAC** (the same monthly statement that has Uncollectible-bill Expense and Transition Adjustment). It appears as a separate line item on the bill with variable rate key `macAdjustmentReconciliation2252`. (The **2252** is ConEd's LSE (load-serving entity) ID, not a tariff schedule number.)

So it is **not** the same as the main MAC charge (the cost-basket true-up in section 2): that one uses key `monthlyAdjustmentClauseResidential`. The Reconciliation Rate is a distinct, usually **small** $/kWh component (often a fraction of a cent per kWh, and sometimes negative) that is updated **monthly** along with the other two MAC-statement components.

#### What it reconciles

The PSC No. 10 electric tariff (General Rule 26), which is the primary source for such things, does **not** define what the Reconciliation Rate component reconciles. The tariff refers to "delivery charges and adjustments described in General Rule 26" and to the "Adjustment Factor – MAC" but does not name or define the three columns on the Statement of Adjustment Factor - MAC. The exact scope of the Reconciliation Rate (which deferrals or cost categories it true-ups) is set in PSC rate case orders and ConEd's filings that establish that statement; it is not spelled out in the main tariff PDF. We don't really know.

#### Time lag

- **Lag**: **Monthly** (same as the other MAC-statement components).
- **Pattern**: The rate is set each month on the Statement of Adjustment Factor - MAC; it reflects a prior-period true-up applied to current billing.

#### Variable Rate Key

```json
"variableRateKey": "macAdjustmentReconciliation2252"
```

---

### 6. Delivery Revenue Surcharge

#### What Problem It Solves

The Delivery Revenue Surcharge (DRS) recovers **revenue**—not costs—that the utility would have collected under **newly approved rates** during the period when those rates were **suspended** or delayed. When the PSC extends a rate-case suspension (or the case runs long), the effective date of the new rates is pushed out. During the extra months, the utility still collects under **old** rates, so it under-collects relative to the revenue it would have gotten if the new rates had been in effect. DRS is the mechanism to recover that **suspension-period revenue shortfall** over a defined period, often as a separate line item so the recovery is transparent and deferrals don't build up.

#### Why RDM, MAC, or the next rate case don't handle it

- **RDM** true-ups actual revenue to the **revenue target for the rates currently in effect**. During the suspension extension, the rates in effect are the old ones, so the RDM target is the old revenue requirement. The DRS shortfall is relative to the **new** (approved but not yet effective) revenue requirement—a different target.
- **MAC** true-ups **costs** in the MAC basket. This shortfall is from not having the new rate level in effect, not from wrong cost forecasts.
- **Next rate case:** The utility could defer the shortfall and recover it in the next case. ConEd's joint proposals instead use a surcharge over a set period to avoid large deferrals and make the recovery visible.

#### How It Works (with example)

The PSC approves new rates with an assumed effective date (e.g. January 1). The case or suspension is extended, so the new rates don't take effect until later (e.g. July 1). The dollar shortfall = (revenue that would have been collected at the **new** rates from Jan–Jun) − (revenue actually collected at the **old** rates for Jan–Jun). That shortfall is spread over a defined recovery period (e.g. through the following year) as a **$/kWh** surcharge—the DRS. When the recovery period ends, the surcharge goes away (possibly with a final prior-period reconciliation).

**Example.** Suppose the PSC order assumes new electric delivery rates effective January 1, 2024, but the suspension is extended and new rates don't take effect until August 1, 2024. For those seven months, ConEd collects at **old** rates. Had the new rates been in effect, it would have collected an extra $X (the "make whole" amount). The commission authorizes recovery of $X via a Delivery Revenue Surcharge, e.g. as a $/kWh adder on bills from September 2024 through December 2025, so the utility is made whole without rolling the shortfall into the next rate case. The DRS line on your bill is that adder.

#### Variable Rate Key

```json
"variableRateKey": "DeliveryRevenueSurchargeSc1"
```

---

### 7. Clean Energy Standard Delivery Surcharge

#### What Problem It Solves

NY's Clean Energy Standard (CES) mandates that utilities procure increasing amounts of renewable energy. This surcharge recovers the **delivery-side costs** of that mandate.

#### What It Covers (Delivery Side)

- Grid upgrades needed to integrate renewables
- Interconnection study costs
- Distribution system modifications for DERs (Distributed Energy Resources)
- Administrative costs for clean energy programs

#### The Supply Side Counterpart

There's also a "Clean Energy Standard Supply Surcharge" that covers:

- Renewable Energy Credit (REC) purchases
- Zero Emission Credit (ZEC) purchases for nuclear
- Tier 4 (offshore wind/transmission) costs

The delivery surcharge is separate because these are **infrastructure costs**, not commodity costs.

#### How It Works

**Step 1: PSC Sets CES Targets**

```
2025: 70% renewable electricity
2030: 100% carbon-free electricity
```

**Step 2: ConEd Incurs Costs**

```
Year 1 CES delivery costs:
- Distribution upgrades: $50 million
- DER integration: $30 million
- Program admin: $10 million
Total: $90 million
```

**Step 3: Surcharge Calculated**

```
CES Delivery Surcharge = $90 million / 40 billion kWh
                       = $0.00225/kWh
```

#### Time Lag

- **Lag**: Varies (quarterly to annual updates)
- **Why**: Depends on when costs are incurred and PSC reporting requirements

#### Variable Rate Key

```json
"variableRateKey": "cleanEnergyStandardDelivery2252"
```

---

## Complete Timeline: How Delivery Adjustments Flow

Here's how all these adjustments play out over time:

```
YEAR 0: RATE CASE
────────────────────────────────────────────────────────────────────────────
│ PSC sets base delivery rates for 3-year period
│ Assumes specific levels for: property taxes, storm costs, sales volume,
│ bad debt, clean energy costs, etc.
│
▼

YEAR 1: ACTUAL OPERATIONS
────────────────────────────────────────────────────────────────────────────
│ Q1: ConEd operates, incurs actual costs, serves actual load
│ Q2: Costs tracked, variances accumulate
│ Q3: ConEd files quarterly/annual reconciliations with PSC
│ Q4: Year-end data compiled
│
│ Meanwhile, customers are billed at:
│   - Base rates (fixed from rate case)
│   - Prior period adjustments (from Year 0 or earlier)
│
▼

YEAR 2: ADJUSTMENTS APPLIED
────────────────────────────────────────────────────────────────────────────
│ Q1-Q2: PSC reviews Year 1 reconciliation filings
│ Q2-Q3: PSC approves adjustment factors
│ Q3-Q4: Adjustments appear on customer bills
│
│ Customer bills now include:
│   - Base rates (still fixed)
│   - Year 1 cost variances via MAC, RDM, etc.
│   - Prior period true-ups being finalized
│
▼

YEAR 3: NEXT RATE CASE (OR CONTINUED ADJUSTMENTS)
────────────────────────────────────────────────────────────────────────────
│ Either: New rate case resets base rates
│ Or: Adjustment mechanisms continue accumulating
```

---

## How the Adjustments Interact

These aren't completely independent—they're designed to work together:

| Adjustment                 | What It Catches                            | Frequency | Typical Lag  |
| -------------------------- | ------------------------------------------ | --------- | ------------ |
| MAC                        | Cost changes (taxes, storms, etc.)         | Monthly   | ~1 month     |
| RDM                        | Sales volume variance                      | Annual    | 12-18 months |
| Delivery Revenue Surcharge | Specific revenue shortfalls                | As needed | Varies       |
| Reconciliation Rate        | Third MAC component; scope per PSC filings | Monthly   | ~1 month     |
| Transition Adjustment      | Legacy restructuring costs                 | Monthly   | ~1 month     |
| Uncollectible Bill Expense | Bad debt (uncollectible) true-up           | Monthly   | ~1 month     |
| CES Delivery Surcharge     | Clean energy infrastructure                | Quarterly | 3-6 months   |

---

## Why Variable Rates Instead of Fixed?

You might wonder: why not just set these adjustments at fixed levels?

| Approach             | Problem                                                     |
| -------------------- | ----------------------------------------------------------- |
| Fixed adjustments    | Would be wrong as soon as actual costs differ from forecast |
| Frequent rate cases  | Expensive ($millions), slow (12-18 months), adversarial     |
| Variable adjustments | Allow continuous true-up within PSC-approved framework      |

The variable adjustment mechanism is a regulatory compromise:

- **Utilities** get timely cost recovery
- **Customers** pay actual costs (no more, no less)
- **PSC** maintains oversight through filing requirements
- **Rate cases** can focus on major issues, not routine variances

---

## Practical Impact: What This Means for Your Bill

For a typical ConEd residential customer using 500 kWh/month:

| Component          | Typical Range     | Monthly Impact |
| ------------------ | ----------------- | -------------- |
| Base Delivery Rate | $0.161/kWh        | $80.50         |
| MAC                | ±$0.001-0.005/kWh | ±$0.50-2.50    |
| RDM                | ±$0.002-0.008/kWh | ±$1.00-4.00    |
| Uncollectible      | $0.0003-0.001/kWh | $0.15-0.50     |
| CES Delivery       | $0.001-0.003/kWh  | $0.50-1.50     |
| Others             | ±$0.001/kWh       | ±$0.50         |

The adjustments typically add/subtract **$2-8/month** from your base delivery charges, or about **3-10%** of the delivery portion of your bill.

---

## Summary: The Big Picture

1. **Base rates are set infrequently** (rate cases every 1-3 years)
2. **Costs change constantly** (weather, taxes, policy, bad debt)
3. **Adjustments bridge the gap** (automatic true-ups between rate cases)
4. **Each adjustment has a specific purpose** (not arbitrary line items)
5. **Time lags exist** (you're always paying for past variances)
6. **Net effect is revenue neutrality** (ConEd recovers actual costs, no more, no less)

The complexity isn't arbitrary—it's the result of decades of regulatory evolution trying to balance utility financial health, customer protection, and policy goals like decarbonization.
