V8 · Settlement

1. What settlement does

In plain words — the problem settlement solves

After a day or a month closes, every party needs a number they can trust:

• How much energy counted under each deal?
• At what price?
• Which network charges or credits apply?
• Who owes whom — and can we prove the books balance?

Settlement is the platform’s routine that answers those questions. It takes meters, nominations (when used), and the contract terms you already signed, and turns them into:

1. quantities (matched / delivered / spill / shortfall),
2. money lines (energy, wheeling, WER, fees, adjustments),
3. a double-entry ledger that sums to zero, and
4. a statement each party can read from their own seat.

Nothing here invents energy or invents rand. If a figure appears on a statement, it came from a meter (or an agreed substitute), a carve of a shared meter, a contract rule, or a network tariff table — and every credit has a matching debit somewhere (§8).

Three shop fronts — how each is settled

Deals always sit on concrete shop fronts from V2:

Physical vs virtual (one sentence each). A physical deal wheels energy on the network — losses and use-of-system charges apply. A virtual deal is a money hedge (strike vs credit) — the buyer still draws the grid; matching still uses overlap of supply and demand shapes (V7 §9). Both kinds run through the same five-stage pipeline (§2).

One-to-one — the simple case

The easiest picture is one plant ↔︎ one buyer under one contract.

Example (demo direct line): IPP2 Atlantis Wind → OffTaker C Midrand DC on PPPA-202607-138209764.

For each interval:

1. Read the plant meter (supply) and the site meter (demand).
2. Match = the smaller of the two.
3. Apply losses → delivered at the buyer (physical).
4. Price that energy; write network lines; post the ledger.

Nobody else is claiming that plant meter for this deal. Conservation is local and obvious: what the plant put in equals matched-to-this-buyer + spill (and losses sit on the delivered path).

Many-to-one — one plant shared by many buyers

Often one Generator Site sells to many Off-taker Sites and/or Trader Pools at once. The plant has one generation meter. You cannot let every buyer’s contract pretend the whole meter is theirs — that would invent energy.

So the platform first carves the meter among the plant’s active deals (the Global Allocation Hierarchy — taught in V4, consumed here in §5 / §6). Only after that carve does each PPA run its own Match against its own buyer demand.

Toy numbers (one interval). Plant meter = 100 kWh. Three claimants after the hierarchy rules: 30 + 20 + 50 = 100 ✓. Each deal then matches only against its carve:

Careful. Opening Off-taker C’s settlement and seeing “50 kWh supply” does not mean the plant only made 50. It means this contract’s share was 50. The rest of the meter belongs to other members’ periods.

Many-to-many — buyers fed by several sources

The mirror picture: one Off-taker Site (or one Trader Pool on the buy side) can hold many contracts at once — several Generator Sites and/or several sell-side Trader Pools. Each contract still settles separately. The site’s total meter is not “owned” by one PPA; each deal only claims the energy its own match produced.

Example shape:

• Mall site has PPA-1 from Plant X (direct),
• PPA-2 from Trader Pool T1 (portfolio supply),
• and still buys residual grid energy outside both deals.

Settlement does not merge those into one blob. You get one period per contract. The mall’s “total bill story” is the sum of: each PPA’s statement + ordinary utility for the residual.

Trader Pool in the middle. A pool is often both many-to-one and many-to-many at once:

• Buy side: many Generator Sites (and maybe other traders) sell into the pool — each buy-leg settles like any seller→trader PPA.
• Sell side: the pool sells out to many Off-taker Sites (and maybe other traders) — each sell-leg settles like any trader→buyer PPA.
• Trader P&L is then “what I collected on sell-legs minus what I paid on buy-legs minus costs I bear” (§10). That margin is a commercial roll-up; it is not a second magical settlement that rewrites the legs.

What the routine produces (and what you open)

Status chips (DRAFT / FINAL / re-run, and so on) tell you whether the period is still provisional or locked for the statement — taught in §11.

The five stages (preview)

Every period walks the same spine. Later chapters zoom each stage; you only need the names here:

When a Generator Site is shared, an Allocate step sits between Resolve and Match so each contract only sees its carve (§5). §2 walks both paths: Example A Atlantis Midrand day (one-to-one, Allocate skipped) and Example B GEN-1 Acme / Borg peak carve (Allocate on).

Where this is taught next. Periods, intervals, frequency, and why shared plants settle in the same window (§1.1) · matching and conservation (§1.2) · the full pipeline with both examples (§2).

1.1 Periods, intervals and frequency

Settlement thinks in three nested clocks. Mix them up and the screens look contradictory; keep them straight and every number has a home.

What each concept is (nothing assumed)

Settlement Frequency. Written on the signed deal. It answers: when do we close the books for this contract? Most wheeled PPAs are MONTHLY; some books prefer DAILY so cash and disputes stay short. Both sides must agree — it is a joint term.

Settlement period. The concrete artefact for this contract in that closed window. Example: physical PPA PPPA-… × 9 Jul 2026 (daily), or the same PPA × July 2026 (monthly). On that period you see matched / delivered / spill / shortfall, money lines, status (DRAFT → FINAL…), and the content hash (§11).

Interval. One short slice of time inside the period. The engine does not invent a single monthly average and call it a day. For each interval it:

1. reads supply and demand for that slice,
2. matches (after any shared-meter carve — below and §5),
3. applies losses / price / adjustments for that slice,

then rolls up intervals into TOU bands (peak / standard / off-peak) and the period totals on the screen.

One contract, one period row — but shared plants settle together

Each buyer still opens their own settlement period for their PPA. That does not mean the plant’s meter is carved in isolation.

When several contracts claim the same Generator Site meter, the platform groups them into a supply allocation set and runs Allocate once for that closed window before Match. Each member then gets its own period row — but all members of the set use the same calendar window and the same carve.

They must also share the same Settlement Frequency. The runner groups by {frequency, generation meter}: a daily deal and a monthly deal on the same plant are not in one set, because their closed windows are not the same shape.

The mirror case — several sellers into one Off-taker Site meter — is a demand allocation set: same idea, consumption carved once for the window, then each seller’s period matches against its share (§5).

Why the same period matters (worked picture)

Imagine one wind plant meter reads 100 kWh in an interval, and two buyers claim it. Buyer A’s demand shape wants 70, Buyer B’s wants 50. Pro-rata to demand (illustrative) might carve 58 to A and 42 to B — summing to 100.

If each buyer were settled alone, each run would see the full 100 and could match as if the whole plant were theirs — energy sold twice, and no way to prove Σ shares = meter.

Common question — do all buyers on a Generator Site settle in the same period?

Short answer. Yes for a shared plant meter. Every buyer PPA that claims that meter (at the same Settlement Frequency) must be carved in the same closed window, in one supply allocation set. Otherwise a correct allocation is impossible.

How the platform keeps frequencies aligned. The first AGREED (or SIGNED / ACTIVE) contract on a Generator Site locks that site’s Settlement Frequency. Every later proposal and PPA — physical or virtual — that sources energy from the same plant must use that same frequency. Advisors and Proposal Studio prefill and restrict the field; negotiation wizards show it as locked; send / accept / AGREED transitions reject a mismatch. (Meter intervals — the 20-minute fine grain — are not a negotiated term; only the statement frequency is.)

In plain words. Allocation is a single pie-cutting step: the plant meter is the pie; each claimant’s demand (or priority tier) is how the knife is guided. You cannot cut a fair pie if some claimants are missing from the table — or if each claimant gets a private copy of the whole pie on a different day.

So:

1. The engine groups those PPAs into one allocation set for the window.
2. Allocate runs once → each contract receives only its carve.
3. Each contract still gets its own settlement period row (quantities, money, statement for that seat).
4. Those rows all cover the same [period_start, period_end) for that frequency.

If they were settled separately — or on mismatched frequencies so they never group — each run would see the full meter and conservation would break. The same rule applies on the demand side when several sellers share one Off-taker Site meter.

Where the carve is taught next. Flat allocation sets and claim sets — §5. Priority / hierarchy waterfalls — §6. Matching after the carve — §1.2.

1.2 Matching and conservation

Matching answers one plain question for every short interval inside a settlement period:

Of the energy the plant put in, and the energy the buyer took out, how much can this deal honestly claim?

The answer is never “whatever we hoped for.” It is the overlap — the smaller of the two sides — after any shared-meter carve (§5). That overlap is matched energy. Everything else is residue: spill or shortfall. Getting those three ideas right is what makes a statement trustworthy.

The three quantities — in everyday words

Supply comes from the generator meter (or that contract’s carve of a shared plant meter). Demand comes from the buyer’s consumption meter (or a nomination when the meter is late — §3). Neither side invents kWh.

Why matching matters

1. You only pay (or get paid) for what overlapped. A windy plant and a quiet factory do not create a deal volume equal to the plant — only the hours (and intervals) where both were “on” count.
2. Physical losses apply to matched energy, not to the whole plant meter (§4). Delivered at the buyer is typically matched × (1 − loss factor).
3. Virtual hedges use the same overlap idea for the CfD quantity (V0 §5 · V7 §9) — even though no electrons are wheeled on the hedge leg.
4. Shared plants carve first, then match (§5). Each contract matches against its carve, not the whole meter.

Spill — leftover supply, and why you care

Spill is plant energy that did not find a home under this deal in that interval. It is not a bug. Wind and solar often make more than the buyer was consuming at that moment.

Why it is important:

• Seller story. Spill is unsold (for this contract). The deal’s spill rule then decides what happens commercially — forfeit, Eskom buyback, bank for later, or a discounted spill credit (§7).
• Buyer story. Spill is usually not your problem on an as-generated deal — you were not obliged to take it.
• Book / strategy story. High spill means the shapes do not fit; strategy and procurement care about that (V3), and settlement shows the realised residue for the closed period.
• Conservation story. Spill must appear in the energy balance so the plant meter still adds up.

Shortfall — missed firm promise, and why you care

Shortfall is different. It only bites when the contract promised a firm quantity or shape (for example BASELOAD, SHAPED, or ToP-style obligations) and the matched / delivered volume falls short of that promise after excused windows (grid curtailment, force majeure, and so on — as negotiated).

Why shortfall matters:

• It turns a volume miss into money (penalty, replacement, LD) — or an excused miss with no cash hit.
• It is how a buyer proves “you promised firm cover and I did not get it.”
• Settlement never invents a shortfall on a purely as-generated deal just because the buyer still drew grid energy.

Conservation — nothing invented, nothing lost in the books

Conservation means the arithmetic closes:

1. Energy (this contract, this interval / period).
   supply = matched + spill
   and, when a firm promise applies,
   firm obligation = matched + shortfall (after excuses).
2. Shared meter (many contracts).
   Σ carves = plant meter before each contract matches (§5–§6).
3. Money.
   Every credit has a matching debit — the ledger sums to zero (§8).

If any of those fail, the period is wrong — not “approximately fine.”

Worked day — IPP2 Atlantis Wind → OffTaker C (demo)

Data. full_demo · seed 42 · stage S09 (settlement matrix) · physical PPPA-202607-138209764 · period 2026-07-09 · DRAFT · one-to-one (no shared carve on this thread period).

Match in plain words. The plant made more than the data centre used that day. The deal can only claim the buyer’s 38,933.333 kWh. The extra 2,485.107 kWh is spill for this contract — still on the plant’s books for the spill rule, not silently folded into “matched.”

Two conservation proofs (same period):

1. Supply: 41,418.44 = 38,933.333 matched + 2,485.107 spill ✓
   
2. Matched path: 38,933.333 = 36,597.333 delivered + 2,336.000 loss ✓

This thread deal is as-generated: the 2,485 kWh spill is the residue to watch; there is no firm shortfall line just because OffTaker C still bought residual grid energy outside the PPA.

Follow along. Seat: IPP2 Atlantis Wind (IPP app). Path: Contracts → PPPA-202607-138209764 → Settlements → 9 Jul 2026 → Energy balance. Read supply, demand, matched, spill, delivered, loss in that order — then open Ledger for the cash zero-sum (§8).

Where residue becomes money. Spill credits, banking and shortfall remedies — §7. Shared-meter carves before Match — §5. Full pipeline stages — §2.

1.3 What you will be able to explain

By the end of this volume you can open any settled period on ContractSettlementLive and answer: which shop fronts are on the deal, whether this period was one-to-one or sat under a shared carve, where each quantity came from, which pipeline stage produced each line, why the ledger sums to zero, and what the status chip means if the period is re-run.

Where this is taught next. The five stages — Resolve → Match → Price → Adjust → Ledger — are the spine of the volume (§2). Physical vs virtual deal kinds — V0 §5; losses on the physical path — §4; virtual CfD walkthrough — §14.

2. The five-stage pipeline

Settlement is not a black box. After a period closes, the engine walks the same five pure stages for every contract — physical or virtual, one-to-one or shared. Nothing is written to the database until the last stage succeeds. If anything fails mid-way, you get an error, not a half-baked statement.

In plain words, the five stages answer five questions:

Those five names are the product’s real stages (WB.Wheeling.Settlement.Pipeline). Later chapters zoom one stage at a time; this chapter is the spine — shown on two casts so you can see both paths.

Why “pure” matters. Each stage is a calculation: inputs in, outputs out. Topology (who sits on which network — which loss / UoS tables apply) is resolved alongside Match. Persist happens once after Ledger. That is why a DRAFT period either appears complete or not at all — you never see “priced but not matched.”

Where Allocate fits

Allocate is not a sixth stage. The five stages stay Resolve → Match → Price → Adjust → Ledger. When several contracts claim the same meter in the same closed window, the runner inserts an Allocate step between Resolve and Match so each contract only sees its carve. Conservation: Σ shares = metered for the interval (§5 · §6).

Two casts used in this chapter

Throughout this volume we return to these two sealed / teaching casts. When a later chapter says “back to the Atlantis Midrand day” or “the GEN-1 Acme / Borg peak carve,” it means that cast and those numbers.

§2 vs §12.2. This chapter is the conceptual spine — stage by stage, with conservation checks. §12.2 is the same two examples on the settlement detail page — what you read on screen after the pipeline has run.

2.1 Example A — One-to-one (Allocate skipped)

One Generator Site, one Off-taker Site, one physical PPA for the closed window. The plant meter is not shared, so Allocate never runs — Match sees the full resolved series.

Data. full_demo · seed 42 · stages S04/S09 · sealed period 2026-07-09 · PPPA-202607-138209764 · status DRAFT · topology cross_municipal · re-derived via SettlementExplorer.detail/2 (same read model as ContractSettlementLive). Full day walkthrough: §13. UI walk: §12.2 Example A.

Resolve → Match → Price → Adjust → Ledger

1. Resolve. Both meters were usable, so Resolve took METERED on both sides. No nomination, no provisional placeholder. (Resolution rail detail — §3.)

(Allocate skipped — one claimant on the plant meter.)

2. Match. Overlap only, then the deal’s loss factor:

Conservation: 554,104.234 = 38,933.333 matched + 515,170.901 spill ✓, and 38,933.333 = 36,597.333 delivered + 2,336.000 loss ✓ (§1.2).

3. Price. FIXED 85.0 c/kWh on delivered TOU bands:

4. Adjust. As-generated: the large spill (515,170.901 kWh) follows the deal’s spill rule (forfeit / bank / credit — §7). No firm shortfall line just because the buyer still drew residual grid energy outside the PPA.

5. Ledger. Seller energy +R 31,107.73 · buyer energy −R 31,107.73; network wheeling / transmission / ancillary / distribution pairs also net to zero (§8). Full line list — §13.4. Buyer seat net ≈ −R 47,210.56; seller seat net +R 31,107.73.

Follow along. Seat: IPP2 Atlantis Wind (IPP app). Path: Contracts → PPPA-202607-138209764 → Settlements → 9 Jul 2026 → Energy balance, then Ledger. Same reading order as this walk: Resolve quantities first, Match next, price and signed cash lines last.

Where this is taught next. Resolution rail and sealed Resolve — §3.1 · §3.2. Nomination-first re-run — §3.3. Screen evidence for this day — §12.6. Complete ledger — §13.

2.2 Example B — One-to-many with Allocate

Same five stages. Different supply story: two buyer PPAs claim one Generator Site meter in the same closed window. The runner inserts Allocate between Resolve and Match so each contract only Matches its carve — never the whole meter (§5).

Data. Teaching peak-band roll-up (aligned with the §5 Acme / Borg carve and §12.2 Example B). Shared plant meter GEN-1 · method PRO_RATA_DEMAND · loss 6 % on each physical match. Not the Atlantis Midrand day — that day stays one-to-one.

Resolve → Allocate → Match → Price → Adjust → Ledger

1. Resolve. Shared supply once; each buyer still resolves its own demand:

Allocate (once for the set — not a sixth stage). Demand ratio Acme:Borg = 70:35 = 2:1, so the 84,000 kWh pie splits:

2. Match (per contract, against its carve, not the whole 84,000):

Each carve is fully claimed (matched = carve), so per-contract spill on the carve is 0. The buyers’ leftover demand (14,000 / 7,000) is residual grid or other supply — not a second claim on GEN-1.

3. Price. Each PPA prices its delivered quantity under its signed tariff (TOU / escalation / floors — §7). Acme’s energy money is on 52,640 kWh; Borg’s on 26,320 kWh. Opening Acme’s settlement and seeing supply 56,000 does not mean the plant only made 56,000 — it means this contract’s share was 56,000.

4. Adjust. Spill / bank / shortfall rules run per deal on that deal’s residue. Here the carve was fully matched, so the interesting residue is unmet buyer demand outside the PPA — not a double-sell of the meter (§7).

5. Ledger. Each period page posts its own double-entry lines so that page’s ledger sums to zero. Acme’s page and Borg’s page are separate books that together still explain the shared meter (56,000 + 28,000 = 84,000 ✓).

Where this is taught next. Resolve + Allocate shares for this cast — §3.4. Flat allocation sets and claim sets — §5. Priority / hierarchy waterfalls — §6. Same cast on the detail page — §12.2 Example B.

2.3 Side by side

2.4 One interval, end to end

The Atlantis Midrand day is a full day roll-up. The same five stages also run on every 20-minute slice inside that day. Here is a small illustrative interval so you can see the arithmetic without the full-day totals — same stage names, toy kWh for one slice (one-to-one path, like Example A).

Data. Illustrative 20-minute physical slice (teaching numbers, not a sealed explorer row). Stages and reading order match Example A.

1. Resolve — supply 500, demand 420.
2. Match — matched = min(500, 420) = 420 kWh; spill = 80 kWh; delivered = 420 × 0.95 = 399 kWh.
3. Price — 399 × 142.5 c = R 568.575 energy (buyer → seller).
4. Adjust — spill 80 kWh follows the deal’s spill rule (forfeit / bank / credit — §7); no shortfall on an as-generated deal.
5. Ledger — seller +R 568.575 energy · buyer −R 568.575 energy (+ any network / WER lines for the interval). Energy legs net to zero; network legs net Eskom / municipality against the bearing party.

Note. Shared-meter periods (Example B) run Allocate before Match so each PPA only sees its share of the metered kWh — otherwise two buyers would each match against the full meter (§2.2 · §5).

The energy proof is local and complete: 500 = 420 matched + 80 spill ✓, then 420 = 399 delivered + 21 loss ✓. The cash proof is separate: +R 568.575 + (−R 568.575) = R 0.00 for the energy pair before the network counter-entries are included.

Follow along (full day). Seat: IPP2 Atlantis Wind (IPP app). Path: Contracts → PPPA-202607-138209764 → Settlements → 9 Jul 2026 → Energy balance, then Ledger — that is Example A, the Atlantis Midrand day.

3. Where the numbers come from

Your first dispute is usually not about a formula. It is about a number: why did the settlement use 40,000 kWh when the trading desk nominated 38,000 kWh? Resolve answers that question before Match, Price or the ledger can change it. Settlement never invents a quantity; it selects the best available interval series for each side of the deal, tags every interval with the source that won, and hands that series downstream.

In plain words:

1. Find every linked meter, nomination and contracted profile that could speak for supply or demand in this closed window.
2. Pick the highest-priority usable source per side, per interval (the resolution rail below).
3. Hand those series to the rest of the pipeline — either the full series (one-to-one) or, after Allocate, each contract’s carve (shared meter).

This chapter is the Resolve zoom. The conceptual five-stage spine with both casts is §2; the same numbers on the settlement detail page are §12.2.

3.1 The resolution rail

The rail is evaluated independently for supply and demand, interval by interval. It is a precedence rule, not an average and not a forecast. Think of it as four trays stacked by trustworthiness: settlement takes the first tray that has usable data for that interval, records which tray won, and moves on.

A trader seat often has no consumption meter at all: its nominated or contracted series is therefore its demand input. Settlement consumes that series; it does not re-forecast it.

Both running examples start on this rail. On Example A, both sides win METERED for the sealed day (§3.2). On Example B, the shared plant and each buyer site likewise resolve from their meters before Allocate carves (§3.4). When a higher tray arrives late, the rail substitutes on a fresh eligible run — that story is §3.3.

Where this is taught. Meter linkage and interval quality are taught in V2 §7. Strategy and Market Operations own how nominations are authored; settlement only applies their submitted series.

3.2 Example A — Atlantis Midrand day (Allocate skipped)

One Generator Site, one Off-taker Site, one physical PPA. The plant meter is not shared, so after Resolve the full supply series goes straight into Match — Allocate never runs (§2.1 · §12.2 Example A).

Data. full_demo · seed 42 · stages S04/S09 · sealed period 2026-07-09 · PPPA-202607-138209764 · status DRAFT · topology cross_municipal · re-derived via SettlementExplorer.detail/2 (same read model as ContractSettlementLive). Full day walkthrough: §13.

What Resolve did on the sealed day

Both meters were usable for the closed window, so Resolve took METERED on both sides. No nomination tray, no provisional placeholder. The day totals that Match then sees:

What Match receives (and what Resolve does not do)

Resolve stops at “which series?” It does not take the overlap, apply losses, or invent spill. Those are Match’s job on the full series:

Conservation on the sealed day: 554,104.234 = 38,933.333 matched + 515,170.901 spill ✓.

Follow along. Seat: IPP2 Atlantis Wind (IPP app). Path: Contracts → PPPA-202607-138209764 → Settlements → 9 Jul 2026 → Energy balance and audit strip. You should see source-derived supply 554,104.234 and demand 38,933.333, then matched / delivered from Match — same cast as §12.2 Example A.

3.3 When the rail changes: nomination first, meter later

The sealed Atlantis Midrand day above already has both meters. This subsection is the demand-side rail story on the same cast: what happens when the off-taker meter is late and a nomination stands in, then the meter arrives. Teaching supply for this walk is a smaller usable IPP reading (so you can see Match move when demand changes); demand ends on the same 38,933.333 kWh that the sealed day uses. It does not replace the sealed full-day supply 554,104.234 in §3.2 / §2.1.

Data. full_demo · seed 42 · stage S09 (settlement matrix) · Atlantis Midrand day · physical PPPA-202607-138209764 · period 2026-07-09 · DRAFT. Teaching supply for the re-run walk below.

At the first run, the IPP meter has reported but the off-taker meter is late. The trader has lodged a 38,000 kWh nomination for the day. You need to know both what the first result means and what changes once the meter arrives.

First Resolve takes supply from the IPP meter and demand from the nomination: resolved demand = 38,000.000 kWh. Match therefore begins with min(41,418.44, 38,000.000) = 38,000.000 kWh. The period is created as DRAFT with provisional: true — the engine does not pretend the nomination is a meter reading. (Status PRELIMINARY is the “offered for review” stamp a party closer sets with the eye control on the period header — §11.2.)

When the off-taker reading lands, the rail changes only the demand source: resolved demand = 38,933.333 kWh. The fresh Match is min(41,418.44, 38,933.333) = 38,933.333 kWh; delivered energy is 38,933.333 × (1 − 0.06) = 36,597.333 kWh before display rounding. Supply remains conserved: 41,418.44 = 38,933.333 matched + 2,485.107 spill ✓. The additional 933.333 matched kWh is not a manual correction; it is the result of a higher-priority source becoming available.

The soft prior becomes REVERSED and a new period is calculated. FINAL and DISPUTED periods never take this automatic path; they require an explicit correction workflow (§11).

Do not add a late meter to a nominated result. The rail substitutes the higher-priority source on a fresh eligible run, so every matched kWh has one provenance path.

3.4 Example B — GEN-1 Acme / Borg with Allocate

Same Resolve rail. Different supply story: two buyer PPAs claim one Generator Site meter in the same closed window. Resolve still runs once for the shared meter (and once per buyer demand). Then the runner inserts Allocate between Resolve and Match so each contract only Matches its carve — never the whole meter (§2.2 · §5 · §12.2 Example B).

Data. Teaching peak-band roll-up (aligned with the §2.2 / §5 Acme / Borg carve). Shared plant meter GEN-1 · method PRO_RATA_DEMAND · loss 6 % on each physical match. Not the Atlantis Midrand day — that day stays one-to-one.

Resolve — shared supply once, each demand alone

Resolve does not split the plant. It only answers “what did GEN-1 say?” and “what did each buyer site say?” Splitting is Allocate’s job.

Allocate — carve before either deal Matches

Demand ratio Acme:Borg = 70:35 = 2:1, so the 84,000 kWh pie splits under PRO_RATA_DEMAND:

Match inputs per carve

Each contract Matches against its carve, not the whole 84,000:

Opening Acme’s settlement and seeing supply 56,000 does not mean the plant only made 56,000 — it means this contract’s share of the resolved GEN-1 series was 56,000. Borg’s page shows 28,000. Together they still explain the meter (56,000 + 28,000 = 84,000 ✓).

Where this is taught next. Flat allocation sets and claim sets — §5. Priority / hierarchy waterfalls — §6. Same cast on the detail page — §12.2 Example B.

3.5 Side by side — what Match receives

Resolve’s job ends when each side has a sourced series. The difference between the two casts is what supply number Match is allowed to see.

3.6 Reading provenance on screen

Provenance lives on the Settlement detail page — one composed screen per period (header eyebrow Settlement · …, agreement ref as the title). There are no tabs; you scroll. The same page is walked end-to-end in §12; this subsection is only “how do I open it?” and “where do I look for Resolve / Allocate?”.

How you open it

From the org home, open the Contracts register, then:

1. Find the agreement (e.g. PPPA-202607-138209764).
2. Choose Settlements on that row — the Settlements list opens (“Monthly settlement summary”).
3. Click the period you care about (e.g. 9 Jul 2026).

You land on /org/deals/contracts/:ppa_id/settlements/:period_id (ContractSettlementLive). Full nav and layout — §12.1 · §12.2.

What to look at

If a value surprises you, ask “which source won?” (and, on a shared plant, “is this the full meter or my carve?”) before asking “which price was used?” That order stops a pricing review from masking an input-data issue.

Follow along. Seat: IPP2 Atlantis Wind (IPP app). Path: Org → Contracts → Settlements on PPPA-202607-138209764 → 9 Jul 2026. You should see Settlement detail with Energy balance supply 554,104.234 / demand 38,933.333, status DRAFT (or PRELIMINARY before closure), and an Audit strip with calculated_at / content hash after a re-run. For the shared-meter story, open the buyer PPA’s period instead and expect Supply to be the carve — §12.2 Example B.

3.7 Resolution questions to ask

Ask for the interval, the source type and the source identifier — not only the displayed total. A meter-backed total needs the meter identifier and reading-quality context; a nomination-backed total needs the submitted series and its cut-off; a contracted total needs the relevant PPA profile. On a shared plant, also ask for the allocation method and the carve — otherwise a 56,000 supply line looks like a 56,000 plant.

That evidence lets both parties reproduce Resolve (and Allocate, when it ran) before they argue about the downstream price.

Do not add a late meter to a nominated result. The rail substitutes the higher-priority source on a fresh eligible run, so every matched kWh has one provenance path (§3.3).

Meter confidence in Resolve

Wheeling resolution reads only current meter revisions and carries their quality, vintage and feed reference. Changing ACTUAL to ESTIMATED changes the input hash even when kWh is unchanged. All-actual input hashes retain the existing encoding. Recomputed content hashes include the new confidence roll-ups; stored hashes on existing periods are never rewritten.

4. Losses and use-of-system charges

Physical wheeling moves energy across a real network. Two things follow: some energy is lost in transit, and the network operator charges for the path. This chapter is how those facts appear on a settlement — not a tariff textbook (that is V2 §8).

4.1 Loss factors — every type, how they are calculated, and how Match uses them

When the plant sends 100 units down the wire, the buyer does not always receive 100. Wires heat up, transformers leak a little, and each network publishes a loss factor that turns “matched at the deal” into delivered at the buyer. Settlement then prices the physical energy lines on delivered, not on the raw match. The gap matched − delivered is the loss volume on the energy-balance card (§12).

This section names every loss type the platform knows, shows how topology decides which ones apply, explains how Match turns them into one period %, and walks physical vs virtual with the same running casts as §2 (Atlantis Midrand day and GEN-1 Acme/Borg).

Honest product note. The contract stores named loss / UoS flags, optional negotiated *_value rates, and a pack-level binding_mode (FIXED or PUBLISHED) on uos_loss_factors. FIXED (the default for existing deals) still applies a single combined loss % from active DLF + TLF + MLF values (§4.1.3) — the teaching haircut sealed demos use. PUBLISHED re-resolves the NERSA-style chain (TLF-Gen at injection → TLF-Load × DLF at delivery) and dimensioned UoS (capacity / demand / admin) from site dimensions + tariff tables for the period date. Municipal buyers can bind MunicipalWheelingConfig (embedded vs separate losses, explicit UoS, WEPS-less-losses). A period stores both loss_factor_pct and a richer loss_resolution audit map. Statements are only “invoice-grade” when sites, binding mode, and published rows for that date are complete.

4.1.1 The seven named items — three losses, four network charges

On a physical PPA the deal carries an embedded pack uos_loss_factors. Each item is a pair: a boolean (“does this apply on this topology?”) and an optional *_value (the rate or factor entered in negotiation).

Remember the split:

• Loss factors (TLF / DLF / MLF) change kWh — they shrink matched energy into delivered.
• UoS charges (TUoS / ETUoS / DUoS / MDUoS) change rands — they post network fee lines. They do not reduce delivered kWh in Match.

4.1.2 Which losses apply — topology decides

Applicability is derived from the seller site and buyer site, not typed in as a free-form percentage. Each side of the deal contributes what its connection deserves:

The deal’s flags are the union of both sides. Extra rule: if both sides are municipal but different municipalities, the path also crosses Eskom transmission → add TLF + TUoS.

You see the path chips on the proposal / settlements Seller→Buyer card (§3.6 · §12). Those chips are the same topology story that lit the flags.

4.1.3 How Match calculates the one number you see

Physical PPA — formula used at Match

1. Read each active loss value (stored as a fraction, e.g. 0.0200 = 2%):
   • if dlf == true and dlf_value set → contribute dlf_value × 100 percent
   • if tlf == true and tlf_value set → contribute tlf_value × 100 percent
   • if mlf == true and mlf_value set → contribute mlf_value × 100 percent
2. Sum those percents → loss_factor_pct (snapshotted on the SettlementPeriod).
3. For every 20-minute interval:

matched   = min(supply_kWh, demand_kWh)
losses    = matched × (loss_factor_pct / 100)
delivered = matched − losses
          = matched × (1 − loss_factor_pct / 100)

Spill and unmet are computed from supply vs demand before the loss step; losses apply only to the matched slice.

Virtual PPA — no loss pack

A virtual hedge has no uos_loss_factors. Match treats the loss factor as 0%:

delivered = matched
losses    = 0

Eskom’s retail / hedge tariff already carries network economics on that side of the book — settlement does not invent a second physical loss haircut. See the worked virtual month (§14).

4.1.4 Worked Example A — Atlantis Midrand day (physical, one-to-one)

Same cast as §2.1 / §12.2:

How 6% can be built from named factors (teaching stack that matches the sealed period — same arithmetic as seeded settlement packs):

TUoS / MDUoS may also be flagged on the deal for rand lines; they do not change this 6%.

Levy on the day:

Seller energy cash is priced on delivered (here at 85 c/kWh → +R 31,107.73 on the sealed day — §13).

4.1.5 Worked Example B — GEN-1 Acme/Borg (physical, after Allocate)

Same cast as §2.2: shared meter, then each carve Matches alone. Losses apply per deal on that deal’s matched kWh — not once on the whole plant meter.

Assume both Acme and Borg physical deals use the same 6% stack for this teaching peak:

Conservation still holds on the plant: 56,000 + 28,000 = 84,000 meter. Losses are not double-counted on the shared meter; they sit on each contract’s matched path.

4.1.6 Topology galleries — how the levy changes with the path

Use one matched slice of 10,000 kWh everywhere so you can compare paths. Values below are illustrative teaching rates (fractions like the contract stores). Swap in the deal’s real *_values when you audit.

A. Eskom Transmission → Eskom Distribution (TLF + DLF)

Typical IPP on Tx into an Eskom Dx customer.

flowchart LR
  IPP["IPP on Eskom Tx"] -->|"TLF 1%"| TX["Transmission"]
  TX -->|"DLF 5%"| DX["Eskom Dx buyer"]
  DX --> DEL["Delivered 9400"]

B. Eskom Distribution → Eskom Distribution (DLF only)

Both ends on Dx — only distribution loss in the union.

Delivered from 10,000 matched → 9,600 (loss 400).

C. Eskom Transmission → Municipal (TLF + MLF)

Last mile is the city network.

Delivered → 9,600.

flowchart LR
  IPP["IPP on Eskom Tx"] -->|"TLF"| TX["Eskom Tx"]
  TX -->|"MLF"| MUN["Municipal buyer"]
  MUN --> DEL["Delivered 9600"]

D. Same-municipality path (MLF only)

Seller and buyer in the same municipal network — no extra Tx flag.

Delivered from 10,000 → 8,976 (loss 1,024).

E. Cross-municipal path (MLF + TLF)

Different municipalities → municipal losses plus transmission for the hop between cities.

Delivered → 9,600. (UoS picks up TUoS as well — rands in §4.2.)

flowchart LR
  A["Munix A seller"] -->|"MLF"| M1["City A"]
  M1 -->|"TLF + TUoS"| TX["Eskom Tx"]
  TX --> M2["City B"]
  M2 -->|"MLF"| B["Munix B buyer"]

F. Virtual PPA (no loss factors)

Delivered from 10,000 matched → 10,000. No loss volume on the energy-balance card for the hedge leg.

Side-by-side (10,000 kWh matched)

4.1.7 How to read it on the screen

1. Open Settlement detail (/org/deals/contracts/:ppa_id/settlements/:period_id — §3.6).
2. Energy balance — matched, delivered, loss %, surplus, unmet.
3. Confirm matched = delivered + losses (physical) or delivered = matched (virtual).
4. Seller→Buyer card — topology chips tell you why TLF / DLF / MLF were in play.
5. UoS / WER rand lines are a separate story → §4.2.

Careful — when a statement is invoice-grade. Engine support for the TLF-Gen → TLF-Load × DLF chain, site-dimension lookups, dimensioned UoS, and municipal branches is wired. A period is only as good as its inputs: generator transmission zone, off-taker TLF distance band / voltage / notified capacity, binding_mode: PUBLISHED (or a municipal config), and tariff rows effective on the period date. Otherwise Match stays on the FIXED teaching haircut and the ledger may still show flat NetworkRate c/kWh layers. Check the period’s loss_resolution snapshot on Settlement detail when auditing.

4.2 Use-of-system and WER lines

On both-Eskom topologies the ledger typically posts:

• Transmission / ancillary (UoS) — unit rates × delivered kWh, borne by the party the deal’s billing responsibility names (V5 §3).
• WER — a credit on the buyer’s Eskom side for wheeled energy, TOU-banded and varying by the buyer’s Eskom tariff category (Megaflex carries the highest Gen-Wheeling rates; Nightsave Urban/Rural have no peak band). The credit is not a single rate for every buyer — using the wrong category overstates the saving.

Municipal legs add municipal UoS where the topology says so; the path chips on the proposal (V5 §1) preview which operators appear.

4.2.1 Non-bypassable levies

Two national levies sit beside the network bundle and cannot be contracted away: the electrification / affordability subsidy (:electrification_subsidy) and an explicit NERSA regulatory levy (:regulatory_levy). Both are effective-dated NetworkRate rows — illustrative c/kWh in the demo estate, pending published NERSA figures — never hardcoded constants. The settlement ledger charges each once per physical period on delivered kWh, anchored on Eskom Transmission (the same operator :wer_credit already uses). Virtual PPAs do not post them.

non_bypassable? is a boolean on the rate row, not a function of the category atom. A future determination can make a category mandatory for one operator and not another, or stop being one, without a deploy. The demo estate flags :wheeling, :ancillary, and both new levies non-bypassable; :wer_credit stays false — a credit paid to the buyer is not a charge anyone might try to escape.

The claim is checked, not merely labelled. LevyConservation walks settled periods and requires a non-zero line for every in-force non-bypassable rate that applies on that period’s date. A period settled before a levy existed is not flagged for missing it. Billing Preflight refuses a run over an unconserved month; a monthly worker raises rather than only logging. Settlement detail, the statement PDF/HTML, and the billing document viewer show a plain Non-bypassable badge on those lines — derived from the register, not copied onto every line.

Eskom maintains the two levy categories on Wheeling Charges (/eskom/loss-factors) as a fourth table beside DLF / TLF / UoS. The flag on that table is fixed Yes; it is not a checkbox.

4.3 Reading an Eskom bill alongside settlement

The sample bill below is a teaching bill (2 MWh month, half wheeled) — illustrative rates, same structure as a Megaflex-style account. Use it to see which lines are “grid” vs “wheeled”.

Data. Illustrative rates · not a seeded full_demo statement.

Here 1,000 kWh was matched at the generator; with a 1.05 delivery factor the wheeled equivalent at the customer is 1,050 kWh. Settlement’s job is to produce the PPA / WER / platform lines that sit beside this bill — not to replace Eskom’s invoice.

Where tariffs are catalogued. V2 §8.

5. Shared meters — allocation and claim sets

One generation meter can feed several PPAs. One demand meter can be served by several sellers. A generator can also sell physically to one buyer and hedge virtually to another on the same electrons. Without an explicit carve, each contract would see the whole meter — and the same kWh would be sold twice.

Settlement prevents that with two groupings that run before Match:

Allocate is not a sixth pipeline stage. The five stages stay Resolve → Match → Price → Adjust → Ledger. When a meter (or generator source) is shared, the runner inserts Allocate between Resolve and Match so each contract only Matches its carve (§2).

5.1 Why allocation matters — what depends on it, what breaks without it

Think of the plant meter as a single pie. Several contracts may want a slice. Allocation is the kitchen knife that cuts the pie once, so every slice adds back to the whole.

What depends on a correct carve

The consequence of skipping Allocate (broken world). Two buyers each want 80 kWh. The plant generated 100 kWh. Settled separately, each deal would Match min(100, 80) = 80 → 160 kWh sold from a 100 kWh meter. Ledgers can still sum to zero inside each PPA — which is why a balanced ledger is not proof that the plant was not oversold. Only the set-level conservation check proves the pie was cut once.

Careful. A short statement is often an allocation problem, not a meter problem. Before you escalate “the meter is wrong,” compare four facts in order: generator meter → set total → your member carve → your counterparty demand (§6.13).

5.2 Concepts in plain words

Process, step by step (every shared case):

1. Resolve the shared meter once — one generation series or one consumption series for the closed window.
2. Resolve each member’s other side — each buyer’s demand, or each seller’s supply / nomination.
3. Allocate — apply the method; write a carve per member; prove conservation.
4. Match per member — min(carve, other side) (then losses on physical delivered energy).
5. Price → Adjust → Ledger — ordinary stages, but on the carve, not the whole meter.

Netting grain is per interval (typically 20 minutes); teaching tables below often show TOU-band totals that are the sum of those interval carves.

5.3 Allocation methods — how the pie is cut

For a supply allocation set (one gen meter, several buyers), the deal or stored allocation set can name a method:

For a demand allocation set (one consumption meter, several sellers), the engine carves load pro-rata to each seller’s supply that interval — the mirror of PRO_RATA_DEMAND. Stored FIXED / PRIORITY weights are wired for supply sets today.

When an in-force Global Allocation Hierarchy covers the physical members, settlement consumes the PRIORITY → PRO_RATA → FIXED waterfall instead of the flat method (§6). Hierarchy is skipped when virtual claims are present on the same generator — the claim set uses a demand-proportional carve across all claims so physical and virtual stay under one roof.

5.4 Scenario map — which set am I in?

Data. Teaching numbers below align with the multi-party worked examples (June 2026 band roll-ups, illustrative rates) and the claim-set engine tests (100 kWh plant). Loss factor in allocation walks: 5% delivered = matched × 0.95 unless a figure says otherwise (pipeline Example B in §2.2 uses 6% for screen parity).

5.5 Scenario A1 — One plant, two factories (PRO_RATA_DEMAND)

The reader’s problem. Karoo Solar One has one generation meter GEN-1. It signed two physical PPAs — to Acme and Borg. Each factory has its own consumption meter. Without a carve, both PPAs would treat GEN-1 as exclusive supply.

Topology

Step 1 — Resolve supply once

Step 2 — Resolve each buyer’s demand

Step 3 — Allocate (cut the pie by hunger)

Per band: Acme share = gen × Acme_demand / (Acme_demand + Borg_demand).

Peak worked: 84,000 × 140,000 / 210,000 = 56,000 · 84,000 × 70,000 / 210,000 = 28,000.

Step 4 — Match each PPA against its carve

Demand exceeds the carve in every daytime band, so matched = allocated. Each factory still draws residual load from the grid outside the PPA.

Conservation: 188,000 + 94,000 = 282,000 = total generation ✓.

Step 5 — What money and network see

Price, losses, WER and the Σ = 0 ledger all run per PPA on the carve. Illustrative IPP energy receivable across both legs ≈ R 292,410 (teaching rates). Full cash walk — §2.2 (peak).

Why this method. When factories are hungrier in different hours, the plant follows who actually consumed, not a frozen percentage. A night with zero solar still allocates zero — you cannot invent energy with a ratio.

Follow along. Seat: IPP with a multi-buyer plant (IPP app). Path: Contracts → either buyer PPA → Settlements → period → Energy balance. Confirm the supply figure is the carve, not the full plant meter; then open the sister PPA and confirm the two carves add to the meter.

5.6 Scenario A2 — One plant, two traders (FIXED_PCT)

The reader’s problem. The same plant sells to Trader X (60%) and Trader Y (40%). Traders nominate demand — they have no factory meter on this leg. The commercial deal is a capacity split, not demand-following.

Step-by-step

1. Resolve GEN-1 once (same 282,000 kWh month as A1).
2. Allocate by weight: peak 84,000 × 0.60 = 50,400 to X · 33,600 to Y; standard 118,800 / 79,200. Totals: X 169,200 · Y 112,800 · Σ 282,000 ✓.
3. Resolve nominations (example): X 180,000 · Y 123,000 — both above their carve.
4. Match: matched = allocated (nomination shortfall is the trader’s downstream problem). Delivered (−5%): X 160,740 · Y 107,160.
5. Price / ledger on each carve; no WER on a trader demand side for this teaching topology.

Contrast with A1. If X nominates huge and Y nominates tiny, FIXED_PCT still gives X 60% of the plant. PRO_RATA_DEMAND would have handed almost everything to X. Choose the method that matches the signed commercial story.

Note. Unit-test shape: meter 100 kWh, weights 70/30 → carve 70/30 even when both buyers’ demands are equal — weights win over hunger.

5.7 Scenario B1 — Two plants, one factory (demand allocation set)

The reader’s problem. Acme has one consumption meter CON-1 but two seller PPAs — Karoo Solar (GEN-1) and Highveld Wind (GEN-2). The factory must not be “fully served” by each seller independently (240k + 240k against a 240k load).

Topology

Step 1 — Resolve demand once

Step 2 — Resolve each seller’s supply

Step 3 — Allocate load pro-rata to supply

Peak: Karoo share 90,000 × 80/120 = 60,000 · Highveld 30,000. Off-peak: Karoo has no solar → 0 · Highveld takes the full 30,000.

Step 4 — Match min(seller supply, allocated demand)

Conservation: 140,000 + 100,000 = 240,000 = factory load ✓.

Why this matters. Without the demand set, each IPP would Match against the full 240,000 kWh load → up to 480,000 kWh of “buyer demand” invented from one meter. Spill/bank rules on each seller would also lie. With the carve, each seller’s residue is honest surplus against its slice of Acme.

5.8 Scenario C1 — Physical + virtual claim set (equal hunger)

The reader’s problem. The same generator sells a physical wheeled PPA to Offtaker Phys and a virtual CfD / hedge to Offtaker Virt. Both are active. Virtual settlement still needs a generation shape — if each engine saw the full plant, you would wheel and hedge the same electrons.

A claim set gathers every active physical and virtual claim on that generator, resolves generation once, and carves by each claim’s demand so:

physical_claim + virtual_claim ≤ generation for every interval.

Step-by-step (one teaching interval)

1. Resolve generation once → 100.
2. Allocate pro-rata to claim demand (80 : 80) → physical carve 50 · virtual carve 50.
3. Match physical against its carve: min(50, 80) = 50 (then apply losses → delivered).
4. Match virtual against its carve: min(50, 80) = 50 (CfD on that quantity — no wheeled delivery).
5. Invariant: 50 + 50 = 100 ≤ 100 ✓.
6. Ledger: each period still nets to zero on its own deal; the claim set is what keeps the plant honest across deal types.

Broken world (no claim set): physical Matches 80, virtual Matches 80 → 160 from 100. Activation also guards over-commitment via source capacity checks; settlement’s claim set is the interval-by-interval enforcement.

Where this is taught next. Virtual money path — §14 · physical vs virtual orientation — V0 §5.

5.9 Scenario C2 — Unequal claim demands

Same generator, same two claim types, but hunger differs.

Carve: 100 × 90/120 = 75 physical · 100 × 30/120 = 25 virtual.

Consequence. The virtual hedge does not get a free ride on leftover plant after the physical deal Takes what it wants in isolation — both claims are peers in one carve. If the commercial intent is “physical first, virtual on residual,” that story is a hierarchy / priority policy on the IPP book (§6 · V4), and claim sets with virtual members do not run the hierarchy waterfall today — they stay on the joint demand-proportional carve so both contract types remain under one conservation roof.

5.10 Scenario C3 — Physical-only on a generator

If the claim-set enumerator finds only physical PPAs (no active virtual), settlement still succeeds: the generator’s physical members are carved like a supply allocation set (or hierarchy, when in force). There is no second contract type to protect against — the invariant collapses to ordinary Σ physical shares = metered.

5.11 What is not an allocation set

The reader’s confusion. You open a trader’s settlement page and see two sell PPAs in the same month. Sections 5.5–5.7 taught that “many PPAs” means Allocate carves a shared meter. So you look for an allocation set — and there isn’t one. That is not a bug. Two PPAs on a statement does not always mean one shared pie.

The bakery vs the warehouse

Use two everyday pictures:

In the bakery, every customer is pointing at the same cake on the counter. If you do not cut it, each customer walks away thinking they bought the whole cake. That is Allocate.

In the warehouse, the trader bought 200 crates from suppliers (procurement legs — often each with its own meter or nomination). They then sell 100 crates to Factory P and 85 crates to Factory Q. Those two sales are separate parcels leaving the warehouse. You do not carve Factory P’s meter across the two sales. You ask a different question: did we try to ship 185 crates when we only stocked 200? Headroom left = 200 − 185 = 15 crates. That check is portfolio conservation — taught in depth in §10.

Worked warehouse hour (no shared meter)

Trader T procured 200,000 kWh this month (buy legs from an IPP and/or another trader — each leg may have its own meter). T sells to two offtakers on separate consumption meters:

Each sell PPA settles on its own path: Resolve that offtaker’s meter → Match against T’s nominated supply for that deal → Price → Ledger. There is no step that says “carve CON-P between Pinnacle and Quanta” — those meters are not shared. The only cross-deal rule is:

100,000 + 85,000 = 185,000 ≤ 200,000 procured ✓

Broken warehouse (oversell). If T tried to sell 120k + 100k = 220k from 200k stock, each sell statement might still look tidy alone — but the book is short 20k. That is a portfolio break, not an allocation-set failure. Chain reconciliation surfaces it (§10).

Side-by-side: when do I look for Allocate?

Ask one question: Are two or more active PPAs pointing at the same physical meter (or the same generator source for phys+virt)?

Careful. A consolidated trader statement that lists two counterparties is not evidence that Allocate ran. Open meter refs on each PPA. If they differ, you are in the warehouse. If they match, you are in the bakery — go back to §5.4.

5.12 Hierarchy bridge — when the carve is a waterfall

The reader’s problem. Your plant meter shows 100 kWh. Your PPA only received 52.5 kWh into Match. The meter is not broken. You are not at the back of a flat “fair share” queue either. You are a member of a Global Allocation Hierarchy — a ranked guest list the IPP authored before settlement ever ran.

Metaphor: VIP rope, then the fair queue, then reserved tables

Imagine a restaurant with 100 seats tonight (the plant meter). Each guest sits under exactly one rule — VIP or fair queue or reserved table — not two badges at once:

1. PRIORITY — the VIP rope. Named guests are seated first, up to their hunger. A VIP who needs 30 takes 30 seats. 70 seats remain.
2. PRO_RATA — the fair queue. Peers share what is left by how hungry each is this hour. Demands 25 and 75 on 70 seats → 17.5 and 52.5.
3. FIXED — reserved tables (other guests). Printed entitlements are seated last, only if seats remain. A “up to 60” card is a ceiling, not a gift certificate — and it belongs to FIXED-tier guests, not to someone already counted in the fair queue.
4. MATCH — will you actually eat? Settlement then bills you on your carve (here 52.5), not on the whole 100-seat room.

That ordered fill is the waterfall. A flat allocation set (§5.5) is more like splitting one pizza by how hungry people are with no VIP rope. Hierarchy is the restaurant with a guest list. Full tier arithmetic — §6.

Conservation at the restaurant door: 30 + 17.5 + 52.5 = 100 ✓. No seats were invented; the VIP took theirs before the queue.

What settlement does with that guest list

Settlement does not rewrite the guest list. The IPP (or allocation run in V4) already decided who sits where. Settlement only:

1. Receives your allocated series (your 52.5) instead of the raw 100 meter.
2. Runs ordinary Match → Price → Adjust → Ledger on that carve.

The short statement came from rank + shared shortfall, not from a wrong meter. Step-by-step arithmetic — §6.6 · §6.9.

Flat set vs waterfall — pick the picture

Careful. Fixed entitlement is a cap, not a guarantee — and it applies to FIXED-tier guests only. A short fair-queue carve (52.5 from a 100 meter) needs the four-fact check in §6.13.

Note. When a virtual claim sits on the same generator as physical members, settlement keeps everyone under one claim-set roof (§5.8) and does not run this VIP waterfall for that joint carve today — so physical and virtual cannot accidentally double-book the dining room.

Where this is taught. Authoring ranks, HAF and allocation runs — V4 · IPP. Settlement’s hand-off and the full 100 kWh arithmetic — §6.

5.13 How to diagnose a surprising carve

Work top-down:

1. Which set am I in? Supply, demand, claim, hierarchy, or portfolio (§5.4).
2. What was the shared meter / source total for the interval or band?
3. What method or tier rules cut the pie?
4. What was my carve vs sister members? Do they sum to the meter?
5. Only then Match: min(carve, my other side) and delivered after losses.
6. Money last — Price / Adjust / Ledger cannot repair a wrong carve.

Where the carve is taught next. Hierarchy waterfall inside settlement — §6. Screen evidence for the Acme / Borg supply carve — §12.2 Example B. Full one-to-many pipeline with Allocate — §2.2.

6. The hierarchy waterfall inside settlement

Your statement can look short even when the generator meter is right. That usually means your PPA sits in a Global Allocation Hierarchy: the plant’s energy was poured through a ranked guest list before your contract reached Match. You never saw the whole meter. You only saw the slice the guest list left for you.

This chapter is the settlement reading of that guest list — the same restaurant / bakery ideas as §5.12, with every tier, formula and leftover explained in plain words. How the IPP authors ranks and entitlements lives in V4 · IPP. Settlement only consumes the result.

6.1 The problem in one picture

Broken expectation. Plant meter = 100 kWh. You open settlement and think “my supply is 100.” Match, price and the ledger all look “too small.” You escalate a meter fault.

What actually happened. You were never entitled to the whole pie. The hierarchy seated VIPs and peers first. Your carve was 52.5 kWh. Settlement then Matched that carve against your factory’s hunger. A balanced ledger on your PPA does not prove you should have received 100 — it only proves your deal’s books balance on the slice you got.

Bridge from §5. A flat allocation set (§5.5) splits one meter among peers under one method (hunger or contracted %). A hierarchy is the restaurant with a VIP rope: order matters, and lower tiers only see what higher tiers did not take (§5.12).

6.2 Concepts in plain words

Conservation (the honesty check). For every interval:

Σ member carves + surplus = plant meter G

Nothing is invented. Nothing is sold twice inside the hierarchy.

6.3 Flat set vs hierarchy — when which picture applies

6.4 What settlement receives

Allocate (here: the hierarchy run) sits between Resolve and Match — same place as in §5. The five stages do not grow a sixth name. Settlement’s Match stage never sees the raw plant meter for a hierarchy member. It sees that member’s allocated series.

6.5 Tier 1 — PRIORITY (the VIP rope)

Everyday rule. Guests with a VIP ticket are seated in rank order. Rank 1 is filled to their hunger before rank 2 sees a single seat. Rank 2 before rank 3, and so on.

Formula (one VIP at a time). With running remainder R (starts as G):

carve = min(this guest’s demand, R) · then R = R − carve

Short-hour consequence. At most one VIP is partially served. Everyone below that rank gets zero for the interval — even if they were hungry. That is the commercial point of paying for firmness.

Worked VIP-only hour

Plant injects 1,000 kWh. Three PRIORITY guests, demands 600 / 500 / 400 (combined hunger 1,500 — more than the jug).

Note. A zero carve for rank 3 is not a meter error. The jug was real; the seating plan put C behind A and B.

6.6 Tier 2 — PRO_RATA (the fair queue)

Everyday rule. After VIPs are seated, everyone in the fair queue shares whatever seats remain, in proportion to how hungry each person is this interval — not by a frozen name-on-the-door percentage.

Formula. Let R₂ be what is left after PRIORITY. Let TD be the sum of fair-queue demands.

each carve = min(own demand, R₂ × own demand / TD)

Two moods:

Contrast with §5 bakery FIXED_PCT. Contracted 60/40 splits ignore hunger (§5.6). Hierarchy PRO_RATA follows same-interval demand, like PRO_RATA_DEMAND on a flat set — but only on the remainder after VIPs, not on the whole pie.

Worked fair-queue hour (after a VIP)

Data. Teaching interval aligned with §5.12 restaurant numbers · plant 100 kWh.

1. VIP A takes min(30, 100) = 30. Remainder R₂ = 70.
2. Fair queue is short: 70 < 100, scale 70/100 = 0.70.
3. B: 70 × 25/100 = 17.5. C: 70 × 75/100 = 52.5.
4. Remainder after fair queue: 0. FIXED and surplus see nothing this hour.

Conservation: 30 + 17.5 + 52.5 + 0 surplus = 100 ✓.

Why you see 52.5, not 100. The meter was 100. The VIP took 30. The fair queue had 100 of hunger for 70 seats. Your share of that hunger was 75%, so you received 75% of 70 — not 75% of 100.

6.7 Tier 3 — FIXED (the reserved table)

Everyday rule. Reserved-table guests are seated last, only if seats remain. Each holds a printed entitlement F (“up to 60 kWh/h”). That card is a ceiling, not a promise that 60 will appear.

Formula. Let R₃ be what is left after PRIORITY and PRO_RATA. Let TF be the sum of FIXED entitlements.

scale = min(1, R₃ / TF) · carve = min(entitlement × scale, demand)

Worked reserved-table hour (shortfall)

Plant 100. No VIPs. No fair queue. Three FIXED guests each entitled to 50 (TF = 150). Demand for each is at least 50.

scale = 100 / 150 = ⅔ → each carve 33.333… · Σ = 100 · surplus 0.

Careful. “Entitled to 50” did not create 50. It created a fair shrink to ~33 when the jug was short. Entitlement without remainder is an empty reservation.

6.8 Surplus — empty seats after closing time

Whatever remains after PRIORITY, PRO_RATA and FIXED is surplus:

surplus = G − Σ all member carves (≥ 0)

Surplus is the IPP’s to sell (spot, trader, later market). It is not walked back up the guest list in the same interval. A hungry PRO_RATA member who was scaled down does not receive surplus “because seats were empty at FIXED.” Those are different rules for different guests.

6.9 Full restaurant walk — then Match and losses

Data. full_demo · seed 42 · stage S09 (settlement matrix) · illustrative interval on the IPP2 Atlantis Wind book · teaching cast below (VIP A + fair-queue B & C). Loss 6% after Match for the delivered figure.

Step A — Hierarchy carve (seating)

30 + 17.5 + 52.5 = 100 ✓

Step B — Your settlement Match (will you eat?)

Your settlement supply is the carve 52.5, not the meter 100. Your factory demand this interval is 52.5 in the hierarchy inputs above — so Match is:

matched = min(52.5, 52.5) = 52.5

If, on another day, hierarchy used a higher nominated hunger than the metered load that later settles, Match can be lower than the carve; the unused carve residue then follows spill / bank rules in §7. Hierarchy itself never allocates above the demand it was given (carve ≤ D always).

Step C — Delivered after losses

Losses are not applied in the restaurant. They apply on the matched quantity in physical Match:

delivered = 52.5 × (1 − 0.06) = 49.35 kWh

(Teaching variant used elsewhere with demand 48 after a 52.5 carve: matched = 48, residue 4.5, delivered 48 × 0.94 = 45.12 — same pipeline; the shortfall vs carve is a Match story, not a meter story.)

Price and ledger then run on delivered (and network lines) exactly as in a one-to-one deal — but the energy quantity already went through the guest list. A Σ = 0 ledger can still accompany a commercially disappointing carve; money balance ≠ “I should have got the whole plant.”

6.10 A second full cast — VIP + fair queue + reserved + surplus

To see every bucket in one hour, use a jug large enough that FIXED fills and something is still left over:

1. PRIORITY: A = 20 · R₂ = 110
2. PRO_RATA: TD = 60 · sufficiency (110 ≥ 60) → B = 30, C = 30 · R₃ = 50
3. FIXED: TF = 40 · sufficiency → D = 40 · surplus = 10

(If the jug had been only 100, the same guests would give A=20, B=30, C=30, then FIXED shortfall scale 20/40 = 0.5 → D=20, surplus=0 — reserved tables absorb the pain; nobody above them is disturbed.)

Conservation: 20 + 30 + 30 + 40 + 10 surplus = 130 ✓.

6.11 What hierarchy does not do

6.12 Inspecting the result on screen

Work in two rooms:

1. Allocations (IPP) — why the seating plan gave you 52.5 (or 0).
2. Settlements (the PPA) — how that carve became matched, delivered, priced and ledgered.

Do not reverse the order. Do not edit rank from the statement.

Follow along. Seat: IPP2 Atlantis Wind (IPP app). Path: Allocations → select the monthly allocation run → member detail for your offtaker; then Contracts → the member PPA → Settlements → selected period. You should see the allocated quantity first and its matched, delivered and priced result second.

Where authorship is taught. Hierarchy membership, rank, HAF/SCE and allocation runs — V4 · IPP (especially the allocation hierarchy chapter). This volume teaches the hand-off into settlement.

6.13 A practical member check

Before you escalate a short statement, compare four facts in order:

How to read the outcomes

Fixed entitlements remain constraints, not guarantees. In the FIXED shortfall walk, “50 entitled” became ~33. In the fair-queue walk, “75 hungry” became 52.5 after the VIP and the shared shortfall. Price is applied only after those boundaries are known.

Where the carve is taught next. Pricing and spill/bank on residues — §7. Screen evidence for shared-meter (non-hierarchy) carves — §12.2. Flat bakery / warehouse contrast — §5.

7. Pricing and adjustments

Match decides how much energy the deal covers in the closed window. This chapter is the next two questions:

1. Pricing — what does that energy cost under the tariff you signed?
2. Adjustments — what happens to energy (or promises) that did not match cleanly — spill, shortfall, banking, curtailment deemed energy?

They are separate stages in the pipeline (§2). Price never invents kWh. Adjust never rewrites the tariff family. Together they turn Match quantities into the money lines the ledger will balance in §8.

What pricing is (in plain words)

Pricing is the cash register for energy the deal did cover.

• For a physical PPA, the quantity is usually delivered kWh (matched energy after the loss factor — §4).
• For a virtual PPA, the quantity is the wheeled / matched hedge shape; the “price” is the strike, and the CfD vs WER split is finished in the ledger (§14).

The cash register reads the tariff type and fields you negotiated in the deal room (V7 §4.4): base rate, TOU multipliers, escalation, floor, cap, capacity charge, and so on. Per TOU band it computes:

amount = delivered_kWh × effective_rate_c/kWh

then rounds to whole cents. Escalation, if any, moves the base once per full contract year before TOU multipliers and clamps apply.

Think of Match as weighing the fruit, and Pricing as looking up the shelf label (flat, seasonal, inflation-linked, capped…) and multiplying.

What adjustments are (in plain words)

Adjustments are everything that is not “ordinary energy at the tariff” — the leftovers and broken promises:

Adjustments are taught in §7.2. The rest of this section is the cash register — every pricing type, with numbers.

Bridge. Terms are chosen in V7. Settlement only applies them. Trader margin and chain P&L — §10.

7.1 Pricing — every tariff type, with numbers

Shared teaching month (unless a type needs a different cast). One physical settlement slice after Match and losses:

Money formula used everywhere below:

Rands = kWh × (c/kWh) ÷ 100

(The engine works in cents; tables show readable rands.)

7.1.1 FIXED — one flat sticker price

Layman’s picture. The shelf label says 85 c/kWh for every hour of the term. No inflation step. No peak premium. Night and day cost the same per kWh delivered.

Negotiated inputs. energy_price_ckwh = 85 · escalation off · TOU multipliers all 1.0 (or unused).

Arithmetic on the teaching month

35,000 × 0.85 = R 29,750 ✓

Demo thread. Atlantis → Midrand day uses FIXED 85 c on delivered — §2.1.

7.1.2 PAY_AS_GENERATED — pay only what arrived

Layman’s picture. Same cash register as a flat rate, but the commercial promise is: you only pay for fruit that actually landed on the scale. There is no minimum-volume invoice for energy you did not take. Surplus generation is spill (Adjust), not an energy charge.

Negotiated inputs. Flat (or TOU) energy rate; contract type as-generated; no take-or-pay minimum on the energy line.

Arithmetic. Same delivered 35,000 kWh at 95 c:

35,000 × 0.95 = R 33,250.00 energy.

If the plant produced more than Match, that extra never enters this line — it follows the spill rule in §7.2.

7.1.3 TOU_LINKED — expensive hours cost more

Layman’s picture. The base sticker is 100 c/kWh, but the shop charges more at peak and less at night: multiply by 1.5 / 1.0 / 0.6.

Negotiated inputs. Base 100 · multipliers peak 1.5, standard 1.0, off-peak 0.6.

Same kWh as FIXED-at-100 would have been R 35,000; TOU shifts +R 3,000 toward peak.

Engine note. The pricer always can apply multipliers; TOU_LINKED is the deal-room name that says those multipliers are the commercial point. Flat deals leave them at 1.0.

7.1.4 ESCALATED — the price grows with the years

Layman’s picture. Year 1 sticker 100 c. Each full contract year, grow by the agreed mechanism (here FIXED_PCT 10% — same arithmetic shape as CPI when the rate is supplied). After one anniversary: 100 × 1.10 = 110 c base. Then TOU multipliers apply on top.

Negotiated inputs. Base 100 · mechanism FIXED_PCT (or CPI with rate 10) · start 2025-06-01 · settle 2026-06 · peak mult 1.5.

Without escalation the same TOU month was R 38,000 (§7.1.3); one year of 10% adds R 3,800 on this shape.

Careful. Escalation counts full years since start_date, not “calendar January.” Settle before the anniversary and the base has not stepped yet.

7.1.5 INDEXED — follow an external benchmark

Layman’s picture. Instead of inventing your own inflation %, the deal says “track Megaflex / NERSA / named index.” Settlement still needs a resolved base rate for the month (the index observation turned into c/kWh, stored as the energy price path with escalation_mechanism = INDEXED). From there the cash register is the same: escalate if the mechanism says so, apply TOU, clamp, multiply by delivered.

Teaching cast. Index resolves to 112 c base for the month · TOU multipliers 1.5 / 1.0 / 0.6 · teaching delivered bands:

7.1.6 FLOOR_CAP — a band neither side can break

Layman’s picture. The floating rate (index or TOU-raw) may bounce, but it may not fall through the seller’s floor or rise through the buyer’s cap. Settlement computes the raw rate, then:

effective = min(cap, max(floor, raw))

Cast A — floor binds. Raw peak would be 100 × 1.5 = 150 c, but floor = 200 c → peak bills at 200 c.

On 10,000 peak kWh: 10,000 × 2.00 = R 20,000 (instead of R 15,000).

Cast B — cap binds. Raw peak 150 c, cap = 120 c → peak bills at 120 c.

On 10,000 peak kWh: 10,000 × 1.20 = R 12,000 (instead of R 15,000).

Full teaching month with floor 80 c and cap 128 c, base 100, TOU 1.5 / 1.0 / 0.6:

Unclamped TOU was R 38,000; the band moves −R 1,200 on this shape (peak cut more than off-peak lift).

7.1.7 CAPPED — buyer shield against runaway price

Layman’s picture. The formula or index may climb, but the buyer’s cap (or price_ceiling_ckwh) is a hard lid. There may be no seller floor — only “you will not pay more than X.”

Cast. Index wants 140 c flat · buyer cap 128 c · teaching 35,000 kWh all at the capped rate (multipliers 1.0 for clarity):

effective = min(140, 128) = 128 c · 35,000 × 1.28 = R 44,800.00

Without the cap: 35,000 × 1.40 = R 49,000 — the shield saved R 4,200 this month.

Note. Deal-room CAPPED volume limits (MWh/yr) are a quantity ceiling on Match/spill — different knob from the price cap. Price lid is this section; volume lid is capacity / spill terms.

7.1.8 TWO_PART — energy plus a monthly capacity bill

Layman’s picture. You pay for the electricity you used (c/kWh) and a standing charge for reserved capacity (R per MW per month) — like a phone plan with airtime plus a line rental. The capacity line is due even if delivered energy is low. A buyer price ceiling can still clamp the energy leg.

Negotiated inputs. Energy base 90 c (TOU 1.0) · capacity R 1,000 /MW/month · contracted 10 MW · optional energy ceiling 110 c.

If escalation or TOU pushed energy to 120 c but ceiling = 110 c, energy becomes 35,000 × 1.10 = R 38,500 and capacity stays R 10,000 → R 48,500.

7.1.9 MARKET_LINKED — the market sets the sticker

Layman’s picture. The energy rate for the period is taken from a wholesale reference the deal names (day-ahead SMP, balancing index, etc.) — not a frozen private sticker. Once that reference is resolved to c/kWh for the settlement month (and any agreed adder), the cash register multiplies by delivered the same way as FIXED.

Cast. Market reference resolves to 102 c/kWh for the month · teaching 35,000 kWh:

35,000 × 1.02 = R 35,700.00

If the deal also has TOU multipliers on top of the market base, apply them as in §7.1.3. Floor/cap bands still clamp after the market rate is known.

Where market prices are taught. Day-ahead and intraday money — V9. This volume only shows how settlement applies the resolved rate to wheeled / delivered quantities.

7.1.10 TAKE_OR_PAY — pay for the minimum even if unused

Layman’s picture. Two bills in spirit: (1) energy for what you actually took, at the flat (or TOU) rate; (2) if you took less than the contracted minimum, you still pay for the missing slice — that second part is an adjustment / shortfall-style line, not a higher c/kWh on the kWh you did take.

Cast. Flat 95 c · minimum commitment 40,000 kWh · delivered 35,000 kWh.

7.1.11 FIRM_ENERGY — premium for a guaranteed shape

Layman’s picture. You pay a premium flat rate because the seller promised a firm shape (not merely “whatever the wind did”). Pricing of delivered energy looks like FIXED at that premium. If the firm shape is missed, the pain is mostly in shortfall adjustments (§7.2), not in a different c/kWh formula.

Cast. Firm premium rate 110 c · teaching 35,000 kWh delivered:

35,000 × 1.10 = R 38,500.00 energy.

If firm obligation was 40,000 and only 35,000 was matched, the 5,000 shortfall follows the negotiated remedy (LD / replacement / penalty) in Adjust — separate from the R 38,500 energy line.

7.1.12 BLENDED — a stack of simpler rules

Layman’s picture. One contract that says “do a bit of each”: e.g. escalating base + TOU multipliers + a capacity charge + a cap. Settlement does not invent a twelfth formula engine — it applies the stacked fields in order:

1. Resolve / escalate base
   
2. × TOU multipliers
   
3. Clamp floor / cap / ceiling
   
4. × delivered kWh → energy money
   
5. Add capacity line if present

Cast. Base 100 c after escalation · TOU 1.5 / 1.0 / 0.6 · cap 140 c (peak raw 150 → 140) · capacity R 5,000 (5 MW × R 1,000):

Curtailment deemed energy (priced like energy, tagged like an event)

When an SO / grid instruction tagged the interval, settlement may price deemed energy at the contract rate and keep the instruction reference on the line (market-side acknowledgement: V9). Without curtailment-event inputs, deemed lines are simply absent — not invented as zeros.

Example: 2,000 kWh deemed at FIXED 85 c → 2,000 × 0.85 = R 1,700 on a deemed-energy line, separate from ordinary delivered energy.

7.2 Adjustments — spill, shortfall, banking

Banking FIFO (mini worked table)

Expiry and inter-TOU limits on the PPA can forfeit remainder before draw — the adjuster enforces the negotiated rule, not a global default.

7.2.1 Top-up provenance and sourcing

A shortfall or replacement-energy line can now name the contract that priced it, not only the category. top_up_term_id is a plain uuid on the LineItem (Wheeling must not belong_to Strategy). The explorer resolves it to a TopUpTerm and replaces the bare category label with:

The eight-character suffix is the term id, so two offtaker deals on the same book do not collapse into one anonymous “replacement energy” row.

Adjuster.shortfall_adjustment/3 and Adjuster.replacement_energy_adjustment/2 stamp top_up_term_id when the PPA carries a term; Ledger.adjustment_lines/4 copies it onto both sides of the balanced pair, the same way it already copies source_term. A PPA or membership with no term still prices through eskom_topup_ckwh / resolve_topup/2 — that cascade is unchanged.

Three sourcing paths, fired only on :ACTUAL / :NOMINATED allocation runs (never :FORECAST / :SIMULATION), from the interval the Allocator first knows the uncovered kWh:

1. Trader pool draw — leftover supply from the named pool is matched as an :ALLOCATION with applied_rules: [:top_up_draw]. Uncovered remainder stays :SHORTFALL, priced as today.
2. Eskom retail — the :SHORTFALL valuation is unchanged. After the run persists, settlement posts a :replacement_energy pair on the subject’s period for that month, at the term’s fixed rate or eskom_topup_ckwh, carrying top_up_term_id.
3. Market order — the shortfall is scored by IdmDecision.decide/2 with the same context shape the IDM cycle already builds. A :redeclare joins that cycle’s action list (top_up_term_id on the action, visible on the lodgement note). A :carry is booked as path 2. There is no second, laxer decision rule for top-up.

Both (1) and (2) respect monthly_cap_kwh: once the month-to-date sourced volume reaches the cap, further hours that month source nothing further against the term. tolerance_kwh is a per-hour floor — at or below it, the hook is a no-op.

The deal-wizard Top-up step that names the term: V7 §4.4 step 11.

7.3 Bridges from the deal room

Every V2 term-family sentence lands here:

• Capacity / ToP / caps → bound matched energy; ToP can create payment without consumption.
• Tariff & escalation → §7.1.
• Spill & banking → §7.2.
• Shortfall & delivery → §7.2.
• Trader margin / source terms → chain P&L in §10.
• Virtual strike / WER → §14.
• Virtual floating leg (Eskom credit vs published SMP) → §7.4.

7.4 The virtual floating leg

A virtual PPA still prices matched energy at a strike. What changed is the other side of the difference. floating_leg on the agreement chooses that reference:

Strike, escalation, floor/cap and settlement volume basis are unchanged. They already live on CfdModel / Pricer. The ledger still posts a signed :energy pair. Only the source of credit in net = strike − credit switches.

Prices come from Publication.fetch/1 — the public DAM board — converted R/MWh → c/kWh with the existing factor-of-10 helper. A missing Trading Day carries the last published price for that hour slot and flags the period; the estate’s first-ever gap refuses rather than inventing zero.

Worked TOU-average numbers: V7 §8.10. Why WER is silent: §8.7. How the statement names the index: §9.11.

7.5 Upside share — hour by hour

For each matched interval, compare published SMP with the captured threshold. Multiply the positive difference by the seller share, apply the interval c/kWh cap, then multiply by delivered kWh (matched kWh for a CfD). Sum the intervals before applying remaining annual headroom and rounding to cents. A TOU average cannot replace this calculation: averaging before the positive-part operation loses spikes. The Devices panel shows the top five intervals and the total. Carried-forward references have a text badge; a missing price without prior published history refuses the run. Reruns read their pinned interval reference snapshot.

7.6 The volume strike — where the crossing is

Walk intervals chronologically, carrying earlier settled volume in the same month, quarter or contract year. Split the crossing interval into within-strike and above-strike kWh; reprice only the latter. The adjustment is signed and can credit the buyer. Spill treatment routes excess into surplus before spill pricing. For a CfD, the within-strike quantity limits the energy payment while WER retains all matched volume. TOU prorating cannot identify the correct crossing or its actual reference price.

7.7 Availability liquidated damages

Availability uses hourly evidence. Excused hours leave the denominator before available hours are counted. Shortfall is the guaranteed percentage minus measured availability minus the deadband, floored at zero. The damages basis is either Rand per MW per percentage point, or a percentage of period energy charges per point. Apply any energy-charge cap and post a negative seller adjustment. A changed evidence hash supersedes the measurement with a new version; unchanged evidence reuses its row. No measurable hours or incomplete required meter evidence refuses measurement.

For 744 hours with 144 excused, 600 are measurable. If 549 are available, availability is 91.5000%. A 95% guarantee and one-point deadband give 2.5 shortfall points. At 10 MW and R12,000 per MW per point, damages are R300,000; a 20% cap against R1.2 million in energy charges reduces them to R240,000.

7.8 Termination payment on the final period

An effective human-served notice stops energy at the effective-date boundary and supplies the pinned estimated payment for the final shortened window. The seller and buyer receive equal and opposite lines under termination payment. Reversing and rerunning the same window replaces the current run rather than accumulating the payment. This adjustment uses the notice’s contractual dates and assumptions; price devices on the final energy still use individual intervals.

7.10 Curtailment claim recovery

Finalized curtailment claims feed the Money Room with their deemed quantity, claim valuation and final recovered amount. The current claim version contributes once. A matching buyer-side curtailment-credit adjustment is excluded when it names the same claim or the same contract and exact instruction window. Review legacy adjustments without those references before assuming overlap has been resolved. The NERSA cost CSV reports final payments, not an assumed zero. See IPP curtailment claims.

8. The ledger — sum to zero

Match told you how many kilowatt-hours the deal covered. Price and Adjust (§7) turned those quantities into rand amounts. The ledger is where those amounts stop being a private calculation and become a shared set of books everyone can audit.

To read your month-on-month position on one agreement in the product — charges, credits, running balance, drill to lines — open the running ledger room (V6 §12.4). This chapter teaches the sum-to-zero proof; that screen is where the months stack.

What a ledger is (in plain words)

Think of a restaurant bill that must be split fairly among everyone at the table. You do not write one vague total on a napkin. You write every charge and every credit on its own line, naming:

The settlement ledger is that shared notebook for one closed period on one PPA (or a combined set of PPAs when you are teaching a multi-party month). It is built from line items. Each line item is one signed rand amount attached to one party and one category.

It is not the same thing as:

What the ledger does

1. Records every cash movement the period created — energy, network use-of-system, WER credits, spill credits, shortfall penalties, capacity charges, admin fees, banking movements, and the rest.

2. Always writes in pairs (or balanced groups). If the IPP is owed R 100 for energy, the buyer is charged R 100 for energy. If Eskom is owed R 20 for wheeling, someone (usually the buyer) pays R 20. No orphan “+R 100 with nobody paying.”

3. Proves conservation of cash the same way Allocate proved conservation of energy (§5): across the whole period,

   Σ (all signed line amounts) = 0

   That is the sum-to-zero rule. Money is rearranged among parties; it is not created or destroyed inside the settlement.

Why the ledger is required

Without a ledger you only have a story: “the buyer should pay about R X.” With a ledger you have a proof:

Important nuance. A single party’s net need not be zero. The IPP can be +R 292,410 and the off-taker −R 207,480 in the same period — that is normal. Only the sum across every party and every category must be zero. Your statement shows your pocket; the ledger proves the table’s pockets balance.

Signs in this volume. + means money toward that party (receivable / credit to them). − means money from that party (payable / charge to them). The UI may also paint credits and debits; the arithmetic is the same.

8.1 Parties and categories

Every line item answers three questions: who, what for, and which way. This section names the who (parties) and the what-for (categories), including the adjustment families that §7.2 created as money.

8.1.1 Anatomy of one line item

A period is valid only when every such line, taken together, sums to zero.

8.1.2 Parties — who can appear on a line

A party is a role in the commercial and network story — not merely a login. The same organisation can be a trader-buyer on one PPA and a trader-seller on another; the ledger labels the role in this period.

On screen (§12). Your settlement ledger view shows your lines and nets. A counterparty volume card may show their kWh so you can check Match — it deliberately does not show their prices. The Σ = 0 proof lives on the whole-period line set (all parties), which statements and ops tooling can re-sum.

8.1.3 Categories — what the money is for

A category is the label on the line: energy versus network versus adjustment, and so on. Group them into four families.

Family A — Energy and capacity (the deal’s own power money)

Layman check. If Match and Price ran, you almost always see energy. Virtual deals still use the energy category for the CfD net (strike − WER credit when WER applies); the WER cash itself is a separate wer_credit category (§14). A market-indexed virtual PPA (SAWEM_SMP / SAWEM_TOU_AVG) still uses energy for that net, but does not post wer_credit at all (§8.7).

Family B — Network / use-of-system (paying to move electrons)

These come from topology and published rates (§4), not from the energy tariff sticker.

Bearer. Who pays (−) is set by wheeling-cost allocation on the PPA (often the buyer). The ledger always shows both the operator’s receivable and the bearer’s payable.

Family C — Credits tied to wheeled Eskom energy (WER)

Layman picture. You wheeled green energy to the factory. Eskom’s retail bill would have been higher without it — the WER line is the refund scrap of that story, separate from paying the IPP for energy.

The same kernel prices a Virtual Wheeling portfolio. Wer.for_portfolio/1 feeds min(consumed, allocated) from persisted 15-minute VwAllocation rows, per meter per TOU, then sums integer cents. Classic per-contract wheeling still runs this reduction against 20-minute settlement intervals. The two paths never meet inside one statement — V17 is that product.

Family D — Adjustments from spill, shortfall, banking, and kin

These are the ledger faces of §7.2. Price created the energy sticker; Adjust decided the residue; the ledger books the cash.

Family E — Admin and certificates

8.1.4 Adjustment families — how §7 residues become ledger categories

Rule of thumb. If it is “ordinary kWh at the tariff,” look under energy / capacity. If it is “paying the wires,” look under network categories. If it is “the deal’s leftover or broken promise,” look under Family D.

8.1.5 Tiny examples — one category at a time

Energy pair. Delivered energy priced at R 31,107.73:

Network pair. Wheeling R 10,000 borne by the buyer: