V9 · Market Operations

1. SAWEM primer — why the market seat exists

Your book still has leftovers and gaps. Strategy minimises them (better contracts, batteries, nominations — V3). This volume is the second option: trade them on the South African Wholesale Electricity Market (SAWEM).

Before you open a Bid Desk or clear a day, you need four ideas in plain words: what SAWEM is, who a Balance Responsible Party (BRP) is, what the Market Operator does, and what the System Operator does. The rest of V7 is detail on top of those four. The organisation screens — Market, Bid Desk, After Delivery (Market Month), Accounts, Billing — are V10.

1.1 What SAWEM is

SAWEM is South Africa’s organised wholesale market for electricity — a shared marketplace where generators, loads, traders and storage can buy and sell energy for specific hours, under published rules, at a price the market itself discovers.

Think of it as a produce market that opens one day ahead, not a private handshake between two farms. You do not phone a counterparty and agree a price for tomorrow’s lunchtime megawatt-hours. You submit a blind bid or offer into a common auction. The market stacks cheap supply against demand, finds the last megawatt-hour needed, and that last unit sets one System Marginal Price (SMP) for the hour. Everyone who cleared that hour trades at that same price.

Before SAWEM — leftovers go to one private counterparty, or sit idle:

%%{init: {"themeVariables": {"fontSize": "20px"}, "flowchart": {"nodeSpacing": 40, "rankSpacing": 48, "padding": 20}}}%%
flowchart TB
  A["Your leftover MWh"] -->|"private deal or leave idle"| B["One counterparty"]

On SAWEM — many parties meet in one blind auction; one SMP clears the hour:

%%{init: {"themeVariables": {"fontSize": "20px"}, "flowchart": {"nodeSpacing": 40, "rankSpacing": 48, "padding": 20}}}%%
flowchart TB
  C["Many sellers"] --> D["Blind auction"]
  E["Many buyers"] --> D
  D --> F["One SMP per hour"]
  F --> G["Schedules for everyone who cleared"]

What “wholesale” means here. This is not the retail bill on a home meter. It is the bulk market between professional participants — megawatt-hours per trading period, settled through the Market Operator’s books. Your bilateral PPA with an off-taker still exists (V8); SAWEM is the place for the residuals strategy could not place under contract, and for participants whose business is trading those residuals.

Two markets, one delivery day. SAWEM runs a day-ahead market (DAM) — plan tomorrow — and an intraday market (IDM) — correct the plan as forecasts drift. After delivery, meters and instructions decide whether you over- or under-delivered. That gap is imbalance, and it is priced to make optimistic forecasts expensive.

The farmer’s-market metaphor. Each morning before the stalls open, every farmer writes a sealed note: “I can sell up to 10 crates at R 40, and another 5 at R 55.” Buyers write sealed notes: “I will buy up to 8 crates if the price is at most R 70.” The market master opens every note, fills demand from cheapest supply upward, and announces: “Today’s crate price is R 52.” Every accepted crate trades at R 52 — not at the R 40 the cheap farmer wrote. The note only got them into the market; the clearing price pays (or charges) them.

That is uniform-price clearing. Your ladder is a reservation — how far you are willing to go — not the invoice price.

1.2 The three seats you must not confuse

SAWEM has many participants, but three roles sit at the centre of every screen in this volume. Confusing them is the fastest way to misread a statement.

flowchart LR
  BRP["BRP<br/>your seat"] -->|"bids offers"| MO["Market Operator<br/>auction money rules"]
  MO -->|"schedules prices"| BRP
  SO["System Operator<br/>grid safety"] -->|"instructions constraints"| BRP
  SO -->|"network limits"| MO

Airport metaphor (keep this one). The BRP is the airline that sold the ticket and must deliver the passengers. The Market Operator is the airport authority that allocates slots and settles landing fees. The System Operator is air-traffic control — it can divert a flight for weather even after the slot was sold, and someone pays for that diversion under different rules than the ticket price.

Where the consoles live. MO seat: V11 §12. SO seat: V12 (§1 who · §4 Dispatch Desk · §5 Network Model · §6 Registry). BRP screens fill §§3–6 and §8–§9.

1.3 What a BRP is

A Balance Responsible Party is the registered organisation that owns the financial outcome of the gap between what the market scheduled (and what the System Operator instructed) and what the meters recorded.

In everyday language: if your portfolio was supposed to inject 100 MWh in an hour and the meters show 92 MWh, someone must buy the missing 8 MWh from the balancing arrangements — or pay the imbalance price for it. That someone is the BRP. The word balance is literal: you are responsible for making planned and actual energy line up, or for paying when they do not.

What “responsible” covers.

• You hold one BRP registration per organisation (a market identity such as BRP-T1-DEMO).
• That registration can cover one or many Trading Units — your own plants and loads, or units you balance as a service for others.
• You submit (or let the platform submit) bids and offers for the hours where those units are long or short.
• After delivery you receive market charges and credits — energy at the SMP, ancillary lines from System Operator decisions, Market Operator fees, and imbalance.
• You post credit cover so the market can collect if you fail to pay.

What a BRP is not.

• Not every site automatically. A plant without a registered Trading Unit still wheels and settles PPAs; it simply has no SAWEM seat (§3).
• Not the same as “the trader user.” A seat login acts for the BRP; the registration is the legal market party.
• Not the System Operator. Following an SO instruction can excuse or reprice a deviation; it does not make the SO your BRP.

Long and short in one sentence. When strategy leaves you with surplus generation in an hour, you are long — you can offer that energy into SAWEM. When strategy leaves unmet demand, you are short — you can bid to buy. Hours that net to zero produce no bid. The full kitchen picture is in §1.7.

Where registration is taught. §3 — codes, Trading Units, standing data, credit cover, and the ACTIVE gate.

1.4 How a BRP trades on SAWEM

Trading is a loop with gates. Miss a gate and that door stays shut; the next door may still open.

flowchart LR
  R["1 Register<br/>as BRP"] --> A["2 Register Trading Units<br/>standing data"]
  A --> B["3 Build ladder<br/>from strategy run"]
  B --> C["4 Submit before<br/>DAM gate"]
  C --> S["5 Receive schedule<br/>and SMP"]
  S --> I["6 Correct in IDM<br/>if drift"]
  I --> D["7 Deliver<br/>follow SO if told"]
  D --> M["8 Imbalance<br/>and settlement"]

Step 1 — Join. You apply for a BRP registration, execute the market agreements the Market Operator issues, and wait until status is ACTIVE. Pending registrations cannot enter the clocks.

Step 2 — Register what you balance. After the seat is ACTIVE, file Trading Units from the site and pool directories (§3.9B). Standing data tells the market what your plant can actually do; some fields need System Operator certification before you may trade.

Step 3 — Turn residuals into a ladder. Strategy still decides the book position (V3). Market ops translates a completed run into hourly net positions and a bid ladder with provenance. A long hour becomes an offer; a short hour becomes a buy. You can rebuild from the latest run on the Bid Desk (§4).

Step 4 — Submit before the day-ahead gate. By default the DAM gate closes 10:00 SAST on D−1 (the day before delivery). Blind submission means you commit without seeing others’ ladders. After the gate, you cannot quietly edit that hour’s day-ahead bid.

Step 5 — Live with the schedule. The Market Operator clears and publishes accepted volumes and the hourly SMP. That schedule is your commercial commitment for energy — what you are paid or charged at the SMP — subject to later System Operator constraints and imbalance rules (§13).

Step 6 — Correct in the intraday market if needed. If forecast drift is large enough and the IDM gate is still open, you may re-declare. IDM is a correction market, not a rewrite of a closed hour (§5).

Step 7 — Deliver under grid reality. Electrons follow physics and System Operator instructions. A curtailment or dispatch order can move you off the economic schedule; that movement has its own compensation rules (V12 §3.2).

Step 8 — Pay for the truth after the fact. Meters arrive. Imbalance compares what happened to what was contracted and instructed (§6). Monthly, the Market Operator’s settlement file is what you reconcile (§8, §15).

Follow along. Seat: trader_1@webill.net (BRP) with password supersecret. Path: BRP / Market → Bid Desk → Day-ahead. You should see: a Gate countdown, the Day-ahead and Intraday tabs, and Rebuild from latest run before a ladder exists.

1.5 The Market Operator — auctioneer, rulebook and clearing bank

The Market Operator is the independent party that makes SAWEM a market instead of a chat group. In the product, that is the /mo console (V11 §12).

In plain words, the MO:

1. Admits participants. Reviews BRP applications, issues agreements, activates registrations, and can suspend them when rules require.
2. Publishes the rulebook. Gate times, price floors and caps, and versioned MarketRules so every bid pins the rules it was made under (§9).
3. Runs the auctions. Collects blind DAM and IDM submissions, clears them, and publishes schedules and prices — on Bidding (/mo/bidding, V11 §12.7).
4. Keeps the money trail. Builds the day-ahead energy account, rings the Market Operator’s own charges into a separate pot, and publishes settlement statements and invoices.
5. Holds credit cover in trust. Participant cover sits in accounts in the MO’s name as trustee — your money, but not withdrawable at will — so the market can still settle if someone defaults.
6. Broadcasts notices. General messages, system stress, price-cap events — context every BRP must see.
7. Handles queries and disputes on market statements (distinct from a bilateral PPA dispute in V6).

Auctioneer metaphor. The MO is the person with the gavel and the person who runs the settlement office behind the hall. They do not grow the vegetables (that is generation). They do not drive the trucks that keep roads open (that is the System Operator). They decide who sold what at which posted price, and they make sure every rand for cleared energy has a matching counterparty in the energy pot.

Three money pots — why the MO is not “the grid.” Market settlement splits into:

The MO invoices Pot 3 and administers all three; it does not become the System Operator when Pot 2 moves. Full arithmetic: V8 §8.5 and V7 §13.

1.6 The System Operator — traffic control for the wires

The System Operator is responsible for keeping the physical power system secure — frequency, voltage, thermal limits on corridors, reserve. In the product, that is the three /so rooms: Dispatch Desk (V12 §4), Network Model (V12 §5), and Registry (V12 §6).

In plain words, the SO:

1. Publishes the network picture. Zones and how much power may flow between them — the constrained scheduling model (V12 §2).
2. Constrains the economic schedule. After the Market Operator’s unconstrained clearing, security limits may cut or redispatch units. Price for energy stays on the unconstrained story; the difference is compensated under ancillary rules, often at your own offered price.
3. Issues dispatch instructions. “Be at this megawatt level by this time, ramping at this rate.” Those instructions create Instructed Energy — what you would have done had you followed them.
4. Calls and certifies reserve. How much regulating or instantaneous reserve a unit may offer is what the SO has certified, not what you wish you had.
5. Can suspend balancing groups in congested zones so local over-delivery cannot hide a constraint violation.
6. Declares system conditions when the grid is under stress — context that may appear as a Bid Desk banner, and that can change which instructions are lawful.

Traffic-control metaphor. The Market Operator sold everyone a slot on the highway for 18:00. The System Operator watches the bridges. If a bridge can only take 60 MW and the market wanted 75 MW across it, traffic control diverts 15 MW — and the diversion is accounted for under safety rules, not by quietly changing the ticket price everyone already paid.

Why BRPs must still care. An SO instruction changes what “good delivery” means for imbalance. Being curtailed by the System Operator is usually settled differently from voluntarily re-declaring yourself down in IDM — one is the grid’s decision, the other is yours (§5, V12 §3.2).

1.7 DAM, IDM and imbalance

• Day-ahead market (DAM) — every day, for every hour of tomorrow, participants submit blind bids; the Market Operator clears one SMP per hour; everyone who clears trades at that price.
• Intraday market (IDM) — corrections closer to delivery when the forecast drifts.
• BRP (Balance Responsible Party) — the registered party financially accountable for schedule vs actuals. The gap is imbalance, priced to punish optimistic forecasts (short above SMP, surplus below — subject to the full Market Code legs in §6).

Before those markets make sense, you need three everyday ideas: long, short, and net to zero. They describe what is left on your book after contracts and strategy have done their work — the residual that SAWEM may trade.

Long, short, and net to zero — the kitchen metaphor

Picture your book as a kitchen for one hour of tomorrow.

• Supply is what you expect to cook (generation, storage discharge, energy you already bought under a PPA).
• Demand is what you have promised to serve (loads, offtake deals, energy you must deliver).

Strategy pairs them as far as it can (V3). What is left on the counter is the residual for that hour:

Long does not mean “good” and short does not mean “bad.” They only say which side of the scales tip. A solar book at noon is often long; a mall at peak is often short. A well-built portfolio can be long in some hours and short in others on the same day.

How the residual becomes a number

For one book and one hour, think in a single signed megawatt-hour:

net = expected_supply − expected_demand (after the strategy run)

%%{init: {"themeVariables": {"fontSize": "20px"}, "flowchart": {"nodeSpacing": 36, "rankSpacing": 44, "padding": 18}}}%%
flowchart TB
  N["Net position for the hour"] --> P{"What is left?"}
  P -->|"net greater than 0"| L["Long → offer to sell"]
  P -->|"net less than 0"| S["Short → bid to buy"]
  P -->|"net = 0"| Z["Net to zero → no bid"]

Worked kitchen numbers (teaching).

Why “net to zero” matters

Net to zero is success for that hour, not a missing trade. It means strategy and your contracts already matched supply to demand, so there is no leftover to sell and no hole to fill. Sending a zero-quantity bid would only add noise; the platform therefore produces no bid for that hour.

A day is almost never all one shape. You can be long at 11:00, net to zero at 14:00, and short at 18:00. The Bid Desk and the automated DAM worker walk each hour on its own residual.

%%{init: {"themeVariables": {"fontSize": "18px"}, "flowchart": {"nodeSpacing": 28, "rankSpacing": 40, "padding": 16}}}%%
flowchart TB
  subgraph day["One delivery day · three example hours"]
    direction TB
    H1["11:00 · long +12 → offer"]
    H2["14:00 · net 0 → no bid"]
    H3["18:00 · short -8 → buy"]
    H1 --> H2 --> H3
  end

Long / short in the market vs imbalance after delivery

Do not mix these two uses of “short”:

Being long at the Bid Desk and then under-delivering on the day are different stories. The first is a planned offer; the second is a balancing problem.

Where the ladder is built. §4 turns these residuals into rungs. Intraday corrections when the forecast drifts: §5.

1.8 What deliberately did not change

The strategy engine never sees a market price. Allocator, pricing, nightly book cycle, pools and hashes stay as V3 / V4 document them. Market ops is a translation layer: completed run → hourly net position → bid ladder with provenance → MO clearing → schedule → imbalance.

A book without a BRP registration behaves exactly as before. Attach an ACTIVE registration and the D−1 clocks (§1.9) bid its residuals automatically — you do not have to sit at the Bid Desk at 03:00. The rest of this section is that automatic path in plain words.

Automatic residual bid — what it is

Think of strategy as packing tomorrow’s lunchboxes (contracts and nominations). Whatever will not fit in a lunchbox is left on the counter. The automatic residual bid is the night porter who, every morning before the market gate, weighs what is on the counter and posts it at the stall — without waking you, and without changing how the lunchboxes were packed.

That porter is the Oban worker SubmitDamBids. It uses the same build-and-submit path as the Bid Desk’s Submit button (§4).

When it occurs

%%{init: {"themeVariables": {"fontSize": "18px"}, "flowchart": {"nodeSpacing": 28, "rankSpacing": 40, "padding": 16}}}%%
flowchart TB
  N["02:30 · RunNightly<br/>refresh tomorrow strategy"] --> S["03:00 · SubmitDamBids"]
  S --> G{"DAM gate still open?"}
  G -->|"yes"| B["Build ladder from residuals<br/>and submit"]
  G -->|"no"| X["Gate miss · no late invent"]
  B --> F["12:00 · FetchSchedule<br/>accepted MWh + SMP"]

Manual path still exists. You can open Bid Desk earlier, Rebuild from latest run, edit if your process allows, and Submit yourself. Automatic bidding is the default night path when you do nothing.

How it occurs — the translation steps

1. Pick the trading date — tomorrow (or an explicit override in ops / tests).
2. For each ACTIVE registration (and its registered Trading Units), read the latest completed strategy run for that day.
3. Compute the hourly net position — the residual per SAST hour (§1.7).
4. Build a bid ladder (BidBuilder) — offers for long hours, buys for short hours, skip net-to-zero hours; apply safety margin and any open-position clamp.
5. Persist a DRAFT bid pinned to the MarketRules version and the strategy run id (provenance).
6. Submit to the Market Operator (same gateway path as the desk) → status SUBMITTED, unless there was nothing to bid.
7. Later (12:00), FetchSchedule writes accepted volumes and the hourly SMP back onto the lines.

How the residual is worked out

For each hour of the trading day, the platform does not invent a market view. It reads the strategy run’s tagged spill and shortfall lines:

net (MWh) = Σ spill (long, +)  −  Σ shortfall (short, −)

Each spill or shortfall line keeps the opportunity cost strategy already computed (what that energy was worth as leftover, or what filling the gap would otherwise cost). That cost becomes the ladder price — the market price forecast is not mixed in (truthful-bidding invariant).

Pricing in one breath (markets quote R/MWh; strategy stores c/kWh; 1 c/kWh = R 10/MWh):

• Offer rung ≈ opportunity_cost × 10 + safety_margin (and not below the market floor)
• Buy limit ≈ avoided_cost × 10 − safety_margin (and not above the market cap)
• Default safety margin on the registration: R 10/MWh

Full rung rules, clips, and cross-book netting: §4.

Detailed example — hour 12 automatic offer

Data. BidBuilder canonical ladder · same numbers as §4.6 · full_demo narrative · safety margin R 10/MWh.

Scene. Delivery day is tomorrow. At 02:30 the nightly strategy cycle refreshes the book. At 03:00 SubmitDamBids wakes for that delivery day. For 12:00 SAST the latest run shows two leftover (spill) lines and no shortfall:

Residual arithmetic.

net = 5.00 + 1.71 − 0 = +6.71 MWh → long → build an offer.

Ladder prices (what the automatic bid posts).

Cheapest rung first: the firm block will clear before the wind block if the SMP sits between them.

What the bid looks like on the desk

After the worker runs, Bid Desk → Day-ahead for that trading date shows a SUBMITTED (or draft-then-submitted) ladder. The hour-12 slice looks like this:

Open a rung’s provenance drawer and you should see the strategy run id, the spill members, and the opportunity costs — proof the night porter did not invent volumes.

Same morning, a short hour (for contrast). If 19:00 had a 6.00 MWh firm-demand shortfall valued at 210 c/kWh, the automatic bid would add one buy line: 6.00 MW @ R 2,090/MWh (210 × 10 − 10). Hours that net to zero simply do not appear.

After clearing (teaching SMP R 980/MWh). Both offer rungs clear because 10 ≤ 980 and 410 ≤ 980. You are scheduled for 6.71 MWh and paid the SMP, not R 10 or R 410. The limits only decided whether you were in.

Follow along. Seat: trader_1@webill.net (BRP). Path: BRP / Market → Bid Desk → Day-ahead for tomorrow after 03:00 (or click Rebuild from latest run then Submit to walk the same path by hand). You should see: firm and wind offer rungs with provenance, gate countdown, status moving to SUBMITTED before 10:00 SAST.

1.9 The D−1 / D / D+1 clocks

Market automation rides a fixed SAST clock. The dial is the same figure family as V0 §6; here the list is the market day slice — D−1 bid and schedule, day-of SO/IDM polls, D+1 imbalance, and the monthly recon on the 3rd.

Default gates (until the MO publishes a new rules version): DAM gate 10:00 D−1; IDM gate delivery − 60 minutes. Prototype SMP bands: DAM 700 / 980 / 1 400 R/MWh (off-peak / standard / peak); IDM slightly lower. Short imbalance 1.35 × SMP, surplus 0.65 × SMP (prototype bands — live Market Code balancing is the fuller stack in §6).

Where book strategy is taught. V3 · Strategy. PPA settlement (distinct from MO settlement files): V8. Orientation clock preview: V0 §6.

1.10 The market objects you must keep separate

Your schedule is not your meter reading, and neither is your contract settlement. The market keeps those records separate so that a cleared trade can be audited after the delivery day.

A BRP owns the market outcome for the registration, even where several books contributed to it. The day-ahead market (DAM) is the binding D−1 auction. The intraday market (IDM) is a correction market, not a way to rewrite a closed hour. The SMP is the uniform clearing price; it is not the price you typed into the ladder.

1.11 Read the clocks before you trade

The market can be automated only because each worker has a narrow job. The following is the complete default rhythm in SAST; a published rules version can move a gate, but it cannot make a closed gate open again.

1.12 What belongs elsewhere

This primer has stayed inside the market seat. Other volumes own the neighbouring jobs. Mixing them is how people end up looking for a PPA invoice on the Bid Desk, or expecting SAWEM to redesign a pool.

Kitchen metaphor (one more time). Strategy packs the lunchboxes (contracts and nominations). V7 only weighs what is left on the counter and posts it at the market stall. V6 is the private dinner bill between you and your counterparty. V11 is the formal order pad the stall accepts from outside systems. V12 is the night crew that keeps the ovens and clocks running. Different rooms; different bills.

What V7 is for

Use this volume when the question is about SAWEM:

• registering as a BRP and staying compliant
• turning book leftovers / gaps into DAM or IDM bids
• reading schedules, SMP, and imbalance (SO instructions live in V12 §3)
• reconciling the Market Operator’s wholesale file and paying / getting paid through market settlement

V7 does not decide which PPA gets which kilowatt-hour, and it does not invent the opportunity cost on a spill line. Those answers come from strategy and deals; the market only carries them forward as provenance on a bid.

What belongs in other volumes

The two bills people confuse

1. PPA settlement (V6). “Did we deliver what we promised each other under this contract, and what do we owe after losses and tariffs?” Counterparty is another org (or Eskom/municipality on network lines).
2. Market settlement (V7). “Did my BRP schedule and instructions match what the meters and the Market Operator say, and what do I owe the market?” Counterparty is the market arrangements (other participants, System Operator ancillary pot, Market Operator fees).

Same megawatt-hour can appear in both stories without being double counted as one invoice. A wheeled PPA settles between buyer and seller; any leftover that went to SAWEM settles on the BRP market statement. Keep the folders separate when you audit.

Handy hand-offs from here

Data. full_demo · seed 42 · stage S08 (market loop) · last re-derived 2026-07-18 against the deterministic demo narrative.

3. Registration and compliance

Screens: BRP / Market → Registration (/org/brp), BRP / Market → Market registry (/org/brp/registry), BRP / Market → Standing data (/org/brp/standing-data).

Registration has two halves, and confusing them is the most expensive mistake on this page. The first half is who you are — one party, one code, one set of financial security. The second is what you registered — the bundles of metering points the market actually schedules and settles, and what each of them can physically do. §3.1 covers the first. §3.2 to §3.6 cover the second, and it is where a portfolio that looked like one business turns out to be three. §3.7 and §3.8 cover the third, which is where the longest-lead work in the whole exercise sits — about thirty facts per plant, and most of them are not in any database. §3.9B is the screen-by-screen guide to every Trading Unit registration wizard — IPP, Off-taker, Trader — and the Market Operator surfaces that inspect the units after they are filed.

3.1 One registration per organisation

Think of a Balance Responsible Party (BRP) registration as your organisation’s membership card for the wholesale market. Without it, your strategy books can still plan and forecast — but they cannot walk through the market door to bid, clear, or receive an imbalance bill. With it, the Market Operator knows who is accountable for money and megawatt-hours under your name.

You hold one registration per organisation. One card, one seat, one set of financial security — even if that seat later holds several Trading Units (trader pool, IPP site, off-taker site). The card is the legal container; the units are what the market schedules (§3.3).

You create that card through a registration wizard on BRP / Market → Registration (/org/brp) — the Info tab. If you have no registration yet, the page shows a call-to-action: Start registration wizard. That opens a modal (a popup window over the page) with six steps. You can jump between steps freely; green circles mean that step has what it needs, and Register as BRP only lights up when the required steps are complete. After you file, the same wizard opens again in view mode via View registration, so you can re-read every answer without changing them.

Filing puts the registration in PENDING. You cannot bid yet. Only ACTIVE may. Getting from one to the other is the application board in §3.13A — information, two agreements signed by both sides, approval, then the Market Operator’s Activate. Later the seat can be SUSPENDED or REVOKED. That four-word chain (PENDING / ACTIVE / SUSPENDED / REVOKED) is still the day-to-day answer to may this seat bid today? A REVOKED seat cannot be suspended: the only Market Operator D2 move is Reactivate (back to ACTIVE). The clocks and the paperwork live underneath it (§3.13).

Follow along. Seat: any organisation without a BRP yet (or a demo org you can recreate). Path: BRP / Market → Registration (Info) → Start registration wizard. You should see six step labels across the top: Identity, Party, Trading, Security, Agreements, Review.

3.1.1 How the wizard is organised

The wizard is not a single long form. It is six short rooms in a corridor. You can walk into any room by clicking its step button. Incomplete rooms show a warning; hover them to see what is still missing. Nothing is sent to the Market Operator until you press Register as BRP on a complete application (or Close / Cancel to abandon without filing).

The sections below explain every field in plain language.

3.1.2 Step 1 — Identity (BRP code, roles, dates)

This step is your name badge and job titles.

BRP code. A short label you choose for this seat — for example BRP-T1-DEMO or BRP-SOLAR-WEST. Think of it as the nickname on your market locker. It must be unique across the platform. It is not the same as the MPID (Market Participant ID): the MPID is a permanent number the Market Operator issues later, like a national ID number for settlement. Your BRP code is the friendly handle people see on screens while you work.

Roles. Tick every hat this seat wears. The market needs this so it knows what kind of activity to expect.

You may tick more than one. A trader that also owns a solar plant is both Trader and Generator — two hats, one membership card. If you leave a role off, books that need that role will not sit cleanly under this seat later.

Effective from / Effective to. Optional calendar dates for when this registration is meant to apply. Think of them as “valid from / valid until” on a season ticket. Leave them blank if you are not limiting the term yet; the Market Operator’s accession dates (§3.13) still govern when you legally become a Party.

3.1.3 Step 2 — Party (type, qualifying ground, two switches)

This step answers: what kind of creature are you in the Market Code’s eyes?

Party type. The legal flavour of your organisation under the Code. Pick the one that matches how you are licensed and how you actually operate. In the wizard, a ? next to the field lists every choice with a short description (same pattern as other org wizards). A Retailer (a supplier of small customers who themselves cannot join the market) is not admitted as a market participant; that category exists for other records, not for this joining path.

Qualifying criterion (Annexure 1). The specific doorway through which you are allowed to enter. The Code lists five grounds. The ground matters after you join, because it gates what you may register as Trading Units later — like a fishing licence that only covers certain waters.

How party type chooses the qualifying criterion. In the wizard you must pick Party type first — Qualifying criterion stays disabled until you do. Choosing a type filters the dropdown to the usual Annexure 1 ground for that type and fills it in. That pairing is a suggestion from the Code’s usual admission path, not a free mix-and-match:

Example: if you join as a Generator on Annexure 1(1), you may register generating (and storage) units, not a pure demand-side unit under a consumer ground. If you join as a Trader, your portfolio may hold both generation and load — that is why traders get Annexure 1(2). Distributor, Transmission, and Network Operator share Annexure 1(3) because they are admitted as network licence holders. Reseller shares Annexure 1(5) with Consumer because the Code treats a reseller as a consumer for admission.

Market participant (on/off). When this is on, you intend to trade in the day-ahead and intraday markets (submit bids and offers). Think of it as “I want a stall in the auction hall.” Most applicants leave this on.

Balance responsible (on/off). When this is on, you are accountable through the balancing mechanism for mismatches between what was scheduled and what meters show. Think of it as “if the books don’t balance, the bill lands on me.” These two switches are independent. A network operator might be balance-responsible for losses without ever bidding in the auction — stall closed, but still on the hook for the till.

3.1.4 Step 3 — Trading (safety margin and price taker)

This step is about how carefully your seat prices energy when the platform builds bids for you.

Safety margin (R/MWh). A padding in rand per megawatt-hour. Default is 10. On an offer (you selling), it is added so you ask a little more than the bare opportunity cost. On a buy limit (you buying), it is subtracted so you refuse prices that are only barely attractive. Metaphor: leaving a small cushion on the car’s following distance so a bump in the road does not cause a crash. You may set a different number if your trading policy says so.

Price taker. When this is on, your offers go in at the market floor price — you accept whatever clearing price the auction finds, because you care more about volume certainty than about setting the price. Typical for must-run renewables that will produce anyway (the sun does not wait for a better bid). When it is off, you are a price maker: your ladder can influence or respond to price. Leave this off unless you deliberately want floor-priced offers.

3.1.5 Step 4 — Security (guarantee and warning limit)

Wholesale markets settle in money. This step records the cushion that protects other participants if you cannot pay.

Guarantee type. The kind of financial security behind your seat:

If Market participant is on (you intend to trade in DAM / IDM), the wizard does not offer None and will not let you register until you pick a real instrument and an amount. Trading seats need a cushion; a stall with no cover is not admitted. Turn Market participant off only if you are joining without trading (for example some network roles that are balance-responsible but do not bid).

Who may stand behind non-cash cover is tightly limited later in the Code (a South African licensed bank, or an international bank authorised here) — §3.16. This field only records the instrument kind on the registration.

Guarantee amount (R). How large that cushion is, in rand. If the type is not None, the wizard expects an amount — a promise with no size is not a promise the market can use. When the Market Governance Committee has published a Warning Limit maximum, the wizard recommends that figure as a starting cover and offers Use recommended (it also fills Warning Limit to the same value). You may lodge more or less once you know your exposure; the recommendation is a conservative starting point, not a Code-mandated floor.

Warning Limit (R). A rand threshold you set (capped by the Market Governance Committee). When your exposure approaches this line, the market machinery can warn you before things get worse. Metaphor: a fuel warning light you set yourself — not the empty tank, but the point where you want the beep. You may set it lower than the committee maximum; you may not set it higher. The wizard shows the current MGC maximum when market rules have published one; if none is published yet, it says so and leaves the field for you to set later.

3.1.6 Step 5 — Agreements (paper trail, fee, accounts, commissioning)

Joining is not only data entry. It is also proof that the legal and bank steps exist. This step records that paper trail.

VAT number. Your South African VAT registration number — compulsory in the wizard. Format: exactly 10 digits starting with 4 (for example 4123456789). Spaces and punctuation are stripped as you type; anything that does not match is rejected before you can register. Market invoices and self-billing invoices carry VAT; without a valid number the tax line on statements has nowhere honest to land.

Accession fee paid. Tick when you have paid the joining fee the Market Operator charges for accession. Think of it as the club joining fee — separate from trading security.

Market Participation Agreement (MPA) reference and MPA executed on. The MPA is the contract that makes you a participant in the day-ahead and intraday markets (the auction hall rules). The reference is the document’s file or contract number; the date is when it was signed. Metaphor: the lease that lets you occupy a stall.

Balancing Agreement reference and Balancing Agreement executed on. A second contract that makes you accountable through balancing (the till that settles mismatches). It is not the same document as the MPA. You can, in some roles, be balance-responsible without bidding — two agreements, two jobs.

Agreement effective date. The calendar day on which you are meant to become a Party under those agreements. Signed packs must reach the Market Operator at least three business days before this date (§3.13) — like posting a cheque early enough to clear before rent day.

Agreements received by MO. The date the Market Operator actually received the signed agreements. That date is what the three-business-day rule reads.

Accounts notified. Tick when you have opened the required Collateral Reserve and/or Trading Clearing Account and told the Market Operator in writing. Opening an account and staying silent is not enough — accession stays blocked until the notice is on file. Details of those accounts are in §3.16.

Testing & commissioning and Commissioning note. Tick if you are participating under a special testing-and-commissioning arrangement before (or alongside) full accession — for example offering energy from plant still under test. The note should say what was agreed with the Market Operator. This is a distinct flag, not a sneaky early ACTIVE, so reports can tell test megawatt-hours apart from ordinary Party volumes.

3.1.7 Step 6 — Review

The last step is a read-back of everything you entered: code, roles, party type, criterion, switches, safety margin, price-taker, guarantee, VAT, agreement references, and the ticks for fee, accounts, and commissioning. Nothing new is typed here. When every required step is green, Register as BRP files the application. The seat appears on your Info page as PENDING. That means filed, not trading — the application board in §3.13A is what follows.

3.1.8 After you register — view and status

Once a registration exists, the Info page shows its header (code, status, roles, guarantee summary) and a detail strip (party type, criterion, VAT, agreements, and related ticks). Use View registration to reopen the wizard read-only and walk the same six steps as a filed record.

Remember: PENDING means filed, not trading. Only ACTIVE may bid. Activation is the last Market Operator step on the application board (§3.13A), not a shortcut from PENDING. The Market Operator console that works those steps is V11 §12.

3.2 The seat holds Trading Units

You do not attach strategy books to the registration. A book is your commercial P&L (V3); the market never sees it. After the seat is ACTIVE, you file Trading Units from the site and pool directories — Register with Market (§3.9B).

A book without a registered unit still forecasts and allocates. It does not enter the DAM/IDM clocks.

3.3 A Trading Unit is not your book

Your book is commercial. You choose it: one per site, one per pool, one per customer segment — however your business is organised.

A Trading Unit is what the market registers, and you do not fully choose it. One rule decides it for you:

A Trading Unit may not span more than one network zone.

For a single-site solar farm the two are the same thing and you can stop reading. For a trader they are almost never the same thing. A portfolio with generation in the Northern Cape and customers in Gauteng is at least two Trading Units — nominated separately, scheduled separately, and balanced separately, which is the word that costs money. Being long in one zone does not cancel being short in another.

The zone rule and what it does to a portfolio is taught in V12 §2. This section is about what you then have to register.

Where the number comes from. Market registry → How many Trading Units do I need? Pick a pool and the screen answers it: one per zone its members sit in, with the zones named. It is a sizing figure for a registration project, not a detail — three zones means three of everything downstream.

When the answer is a lower bound. If the network model cannot place one of your members, the screen says at least N, not N. It will not guess. It names the site that could not be placed and the nearest zone to it, and it says what would fix it: a published zone boundary from the System Operator. Registering that site in the nearest zone would put it in the wrong balancing group and settle its energy against the wrong congestion, which is worse than waiting. The map in use is provisional — V12 §2.3 explains why and what it does not cover.

3.4 A Point of Delivery — and the rule that every meter has two owners

A Point of Delivery is one metered point where energy enters or leaves the grid, registered against a Trading Unit. It carries the electrical node it sits at (the substation busbar, in the System Operator’s own naming), the meter’s device number, and the reference the market’s metering service provider uses to interrogate that meter remotely. Clause §7.2(1)(i) is that record — location, metering, embedded distributor if any, the other BRP, technology, and a SAPP name if the point is an interconnector.

Then the rule that lands hardest:

Every meter has two owners in the market. One party sells through it and one party buys through it. If the second one is missing, the energy through that meter cannot be settled — and not only for you.

The screen calls that second party the counterparty. Most of the time you never type it: the platform derives it from your signed physical PPAs. A generator selling to a trader has that trader as its counterparty at the injection point; the trader selling on to a factory is the counterparty at the withdrawal point too. A trader in the middle is the counterparty at both ends, which is also why the losses and the forecast error land in the trader’s unit rather than anyone else’s.

The registry shows one of three states per point. The last two need different actions from you, which is why the registry lists them separately rather than as one pile of “pending”.

Nothing is invented to fill the gap. A point with no derivable counterparty is shown empty and listed as an exception. A plausible-looking name would settle real energy against a party that never agreed to take it.

One quiet consequence of a virtual deal: it delivers no energy, so it creates no pairing. But the plant behind it is still injecting real electricity into a real network, and that injection still needs a Point of Delivery with a real counterparty — whoever is actually taking that energy. Two separate facts; V0 §5 has the deal side.

The rest of this section is the confusion those rules create for a merchant plant, a factory, and a trader pool — and how you actually clear them.

Two tills — the auction is not the meter

Think of the market stall as having two tills. They ring on different clocks, for different facts, and they do not substitute for each other.

The Market Operator never owns electricity. It is the auctioneer and the clearing bank, not a buyer. So “the market” can pay you the day-ahead energy payment and still not be allowed to sit as the second name on the meter. Clause §12.3(1) wants two BRPs at the point: one exporting, one importing. The MO is neither.

That is why an IPP that only wanted an unknown spot buyer still sees a PPA chase. The unknown buyer is real for price. The meter still needs a named importer for Actual Energy.

A PPA is not a ticket to the stall

You do not need a PPA to become a BRP. Accession is the Market Participation Agreement, the fee, credit cover, and Activate (§3.13). That is §6.

Once ACTIVE you may register a Trading Unit and, if the unit is in force, submit day-ahead and intraday bids. Submission is gated on party state and unit suspension — not on pairing, and not on §7.2(1)(i). A unit with no meters still gets the warning REG_NO_POINTS_OF_DELIVERY at registration; the save is allowed. The nightly re-assertion then fails it for tomorrow, because a pointless unit cannot be scheduled against a meter.

What the Code actually requires at the connection is: every metered megawatt-hour is exported by one BRP and imported by another (§12.3(1)); the Point of Delivery names that other BRP (§7.2(1)(i)(d)); both sides declare the same electrical node (§7.1(6)).

The Code does not say “file a PPA.” It says “name who takes or supplies the energy at this meter.” This platform proves that name from a SIGNED or ACTIVE physical PPA. An unsigned or still-negotiating contract governs nothing yet. Deriving from it would register a pairing both parties could still walk away from.

A virtual PPA derives nothing. It is a price hedge. No electrons move, so no wheeling pairing arises. The plant is still injecting; it still needs a physical taker at the meter.

Worked hour — the auction paid; the meter did not

Data. Illustrative hour at 18:00 SAST on a Trading Day. SMP R 900.00 / MWh. Plant: a merchant generator that cleared 40.000 MWh unconstrained. The meter later reads 42.000 MWh injected. No physical PPA, so the Point of Delivery has No counterparty.

Inputs

Auction till — energy payment (EPM)

The day-ahead energy line is scheduled quantity times the clearing price, not your offer and not the meter.

R1: 40.000 × 900.00 = R 36,000.00

That rand comes from other participants. Across the whole market the energy pot sums to R 0.00. You can receive it with no PPA. The Bid Desk and §13 own this till.

Meter till — Actual Energy

Allocation wants two legs at the point: +42.000 MWh on your unit and −42.000 MWh on a named counterparty unit. With nobody named, the point raises :single_brp_at_point (§12.3(1)). Balancing has no finished Actual Energy for that meter. The rest of the market still allocates — one unpaired point does not halt the day.

The 2.000 MWh the meter ran long of the schedule is exactly the kind of gap imbalance is supposed to price. Without a second name, that gap has nowhere to sit.

Note. You can still participate in market-price settlement on the schedule. You cannot complete imbalance settlement on what the plant did until the meter has two named BRPs. Those are two different tills.

Worked hour — a trader in the middle, meters that do pair

Data. Illustrative. Thread cast: IPP3 Midrand Hybrid injects, T1 Renewables Pool is the trader, OffTaker A Rosebank Mall withdraws. Physical PPAs are signed and both Points of Delivery are Paired.

Allocation writes four legs:

Trader net: −42.000 + 38.000 = −4.000 MWh.

Σ check: 42 − 42 − 38 + 38 = 0 ✓

The −4.000 MWh is losses and mismatch. Not modelled, not adjusted: it simply is T1’s position, because T1 is the other owner at both ends and there is nowhere else for the difference to go. Metering in full is §14.

Every Trading Unit needs a meter on this unit

§7.2(1)(i) is checked on every registered Trading Unit the night before the Trading Day — generating, demand-side, storage, interconnector, and mixed. There is no class exemption.

The check is not “does this BRP appear somewhere in pairing?” It is: does this TUID have at least one Point of Delivery on its own row? Being named as the other BRP on someone else’s meter does not put a meter on your unit.

You may create a unit with no meters. That is a warning. By the eve of a Trading Day it is a failure: the unit cannot be scheduled against a meter. The Market Operator sees it as Today’s failures §7.2(1)(i) on Registry (V11 §22.4). You see an amber line on Market registry: This unit has no Points of Delivery, so it cannot be scheduled.

A missing meter (§7.2(1)(i)) is not the same as a meter with no other owner (§12.3(1) / §7.1(6)). Fix the meter first, then pairing.

Off-taker — the factory meter

The unit is DEMAND_SIDE. Energy leaves the grid at the site’s revenue meter. That meter must sit on this unit.

If you have not registered yet

1. Attach a revenue meter to the OffTaker site (GPS + device). Without it, Register with Market is blocked.
2. The organisation must be an ACTIVE Market BRP. The site must sit in a published network zone.
3. Path: OffTaker Sites → Register with Market. Rooms: Identity · Zone · Delivery · Demand · Finance.
4. On Delivery the meter number is a fact; Electrical node is required; remote access id is optional.
5. Register files the unit and the Point of Delivery together. Wizard detail: §3.9B.2.

If the unit already exists and fails §7.2(1)(i)

Do not re-run the site wizard. Open Units/Groups (/org/trading-units) — that is the registry home — and Add Point of Delivery on the unit (electrical node, meter number, remote access id, site for GPS). The same card lives on BRP / Market → Market registry. Then get a signed, active physical PPA so the other BRP can be derived, and chase Confirm on their inbox (§3.5).

IPP — the plant meter

The unit is GENERATING (or STORAGE if the site is a BESS). Energy enters the grid at the plant meter. That meter must sit on this unit.

If you have not registered yet

1. Generator site: ACTIVE / OPERATIONAL, GPS, revenue meter, export at least 100 kW.
2. ACTIVE Market BRP; site in a published zone.
3. Path: IPP Sites → Register with Market, or Market registry → Register generator site.
4. On Delivery: meter number is a fact; Electrical node is required; remote access id is optional.
5. Register files the unit and the Point of Delivery. Field meanings: §3.7. Wizard: §3.9B.1.

If the unit already exists and fails §7.2(1)(i)

Same as the off-taker: Units/Groups (or Market registry) → Add Point of Delivery. Then pairing via a signed physical PPA. A virtual PPA does not create that pairing.

The merchant instinct — “I am selling to the unknown stack” — is the auction till. It does not skip Delivery. Until a residual-grid BRP exists as a pairing source (§17.13), the only name the platform will put on the other side is a physical-PPA counterparty.

Trader pool — not a plant, still a unit

The unit is MIXED, one per zone. A pool is not a physical plant. The clause still applies to that MIXED unit’s own list of Points of Delivery.

On an IPP or off-taker meter the trader is usually the counterparty. That pairing lives on their unit. §7.2(1)(i) on the pool unit means this MIXED TUID has no meters of its own.

The trader wizard has no Delivery tab. Behind Register it does not invent an empty unit. It copies meters from signed or active physical PPAs whose generator or off-taker site sits in the zone you selected and has a meter number plus remote access id. If there is nothing to pair, registration is refused (points_of_delivery_unallocated). That is why a trader hits the PPA wall earlier than an IPP: they cannot even file the unit until the commercial graph has metered sites in that zone.

If a MIXED unit already exists empty (older path, API, or a zone that later lost its PPA meters): put a signed physical PPA in force for a metered member site in that zone, then Units/Groups → Add Point of Delivery. Pick the member site. Do not invent a pool-only fake meter.

Follow along. Seat: OffTaker A (offtaker_a@webill.net). After Register with Market, open BRP / Market → Market registry and the new TUID. You should see the Point of Delivery table, not the amber no Points of Delivery line. Seat: Trader 1 (trader_1@webill.net). Trader Pools → Register with Market without a signed physical PPA in that zone should refuse rather than file an empty MIXED unit.

Where this is taught. The Market Operator’s clause list and remedies for every nightly failure: V11 §22.4. Adding a meter after the wizard: §3.7 (Pairing a meter after the wizard). API: V13 §5.12.

3.5 The counterparty inbox

When another party names you at a metering point, the market has to tell you — and you have to answer. That is the counterparty inbox, on the Market registry screen.

Each entry names the electrical node, who declared it, whether the point is being added or removed, and the date it takes effect. You have two answers:

• Confirm — the point is yours. The pairing goes live for both of you and the point becomes settleable.
• Dispute, with a reason — it is not yours. The reason goes to the Market Operator, who resolves it.

Silence is not the safe third option. An unanswered declaration leaves the point half-declared, which means neither side can settle energy through it. If a declaration looks wrong, disputing it is faster and cheaper than letting it sit: a wrong pairing that goes live settles your neighbour’s energy against your account.

Careful. A dispute needs a reason in words. “Wrong” tells the Market Operator nothing it can act on; “that busbar feeds the plant next door” tells it exactly what to check.

3.6 Balancing Groups — netting across your own units

If you have several Trading Units, you can ask for them to be balanced together as a Balancing Group. A unit that over-delivers then offsets one that under-delivers, and neither is penalised for a mismatch that cancelled out inside your own portfolio.

You designate the group on Trading Units (/org/trading-units). Select two or more of your units, press Group these units, name the group, confirm the effective window (the earliest date the §7.1(5) cutoff allows), and designate. The Market Operator is told; the System Operator is told; nobody approves it. §13.10(1) makes designation your act. BRP / Market → Market registry (/org/brp/registry) shows what the market holds — status, any administrative suspension, and a cover forecast for the next Trading Day. Manage membership on Trading Units; the registry does not.

Three things to know before you plan on it:

1. You have to ask. It is a designation, not a default. Two or more units, all belonging to you — you cannot pool with another party.
2. The catch is timing. The System Operator can flag a zone whose lines are full — and a zone’s lines are fullest in exactly the hours your positions are largest. The relief you were counting on can be absent in the evening peak and present at 03:00.
3. The exclusion is directional, not a blanket. If a zone cannot export any more, the members pushing more energy out than they scheduled are the ones excluded; a member delivering under schedule is relieving the constraint, not adding to it, and stays in. Import-constrained zones work the other way round. That is a zone constraint flag, not an administrative suspension, and it is never stored as a group status.

A group stops in four ways, and they are not the same thing:

The worked hour — every step, the money, and the catch — is §6.7. The Market Operator’s tab is V11 §21.12; the System Operator’s flag is V12 §5.5.

3.7 The market asks what your plant can actually do

Screens: BRP / Market → Market registry (/org/brp/registry) → Register generator site; IPP Sites → Register with Market on an unregistered plant; afterwards BRP / Market → Standing data (/org/brp/standing-data). Off-taker and Trader file different wizards — those screens, and the Market Operator’s inspection boards, are §3.9B.

Registering a Trading Unit is not the end of it. Before the market can schedule a plant it wants about thirty facts about what that plant can physically do (§7.2) — and the question is not what the plant is, it is what it can do, minute by minute:

• how fast it loads from minimum generation up to full output, and how fast it comes back down;
• how long it must stay on once it has started, and how long it must stay off once stopped;
• what a start costs in Rand from hot, from warm and from cold, and how long each takes;
• how many megawatts of reserve the System Operator has certified it can hold.

For solar and wind these are all zero or near enough. For anything with a turbine they are real numbers that live in a plant engineer’s head or in commissioning documents, and they are not in any database. That is not a gap in this platform; it is a gap in the industry’s records, and closing it is the longest-lead item in getting a plant to market.

You capture those facts in two places. The first time, the Register generator site wizard (this section) turns an operational wheeling plant into a Trading Unit and Point of Delivery. After that, the Standing data screen is the editor for a fleet — not a read-only gate. Open a unit with the eye control; every §7.2 field has an input, its clause, and a provenance you must state. A value with no provenance is refused. A blank is not written as zero: type 0 and choose engineering data when zero is the true answer (solar minimum run time). A zero standing in for “we do not know” still blocks registration. The Market Operator and System Operator copies of the same table stay read-only. The journey around the wizard — who opens it, who supplies what, what happens after Register — is §3.9A. The field guide is here.

Three different people have to answer

The standing-data screen groups what is missing by who can answer it, because they are different people on different clocks:

A plant cannot trade until all three have answered. The System Operator’s answer is the one you cannot hurry, so ask for it first. You do not have to wait for the SO before you press Register — §7.1(5) is register-then-supply. Request certification from the wizard’s last step (§3.7.8); the SO decides on /so/registry (V12 §6).

3.7.1 How the standing-data wizard is organised

The wizard is not a single long form. It is short rooms in a corridor, under a header that reads SAWEM §7.2 standing data. You can walk into any room by clicking its tab. Incomplete rooms show a red mark; hover them to see what is still missing. Completed rooms show a green check. Back and Continue step through in order. Register appears only when every required field is complete. Nothing is sent until you press it (or Cancel to abandon without filing).

The Site tab is hidden when you opened the wizard from IPP Sites Register with Market — that plant is already chosen.

Register does not wait for System Operator reserve certification. After a successful register you see the new Trading Unit id and may request certification there (§3.7.8).

Follow along. Seat: an organisation with an operational generator site (GPS, a revenue meter, export at least 100 kW). Path: BRP / Market → Market registry → Register generator site, or IPP Sites → Register with Market. You should see the §7.2 header and the step tabs across the top.

The sections below explain every input in plain language. Required means Register appears only when every required field is complete. Required fields show a red * on the label. Optional fields never gate the button.

3.7.2 Step 1 — Site

This step picks the wheeling plant the market seat will speak for. It is required when the tab is shown. Opened from IPP Sites, the tab is omitted and you start on Identity.

The list is not every generator site in the organisation. A site appears only when it is ACTIVE, OPERATIONAL on the grid, has GPS, has a revenue meter, and can export at least 100 kW. Each row shows the site name, technology, export capacity, and meter number. Click a row to choose it — the wizard then prefills later steps from that plant.

If the list is empty, the page says so: bring a site to OPERATIONAL with a meter first (V2 §4).

3.7.3 Step 2 — Identity (name, MCR, Mingen, EL1, dispatchable)

This step is the plant’s name badge and the three capacity numbers the market will treat as law. The top of every price ladder you ever submit must equal MCR exactly (§3.8), so the choice here is not a label — it is the number that makes or breaks every bid.

Mingen, EL1, and Dispatchable sit on one row (stacked on a narrow screen). Each label shows an i icon; hover it for a short summary of that field.

The three MCR candidates, with the caution the wizard prints under each:

Careful. Prefer Export capacity unless an engineer has confirmed another figure. Installed (DC) capacity is never the Code’s MCR. The platform will not choose for you.

The three numbers must stay in order: EL1 ≥ MCR ≥ Mingen ≥ 0. If they do not, Register is refused — the curve’s top sits under the rating the market requires it to equal. Fix the figures; the market will not sort them.

3.7.4 Step 3 — Zone

This step has no typed field. The platform allocates a network zone from the site’s GPS — never from the Eskom TLF zone on the wheeling record (V12 §2).

An unallocatable GPS is a hard stop in this wizard. Fix the site coordinates if they are wrong; if they are right, the location goes on the list taken to the System Operator. Nothing else about the wheeling site is affected.

3.7.5 Step 4 — Delivery (point of delivery)

This step is the plant’s address on the electrical network — the Point of Delivery the market will meter and settle (§3.4). The meter number and technology are shown as facts from the site; you do not re-type them.

Each label shows an i icon; hover it for a short summary of that field.

If the site’s municipality has no registered Distributor party, an amber note says so and flags the row for Market Operator follow-up. That warning is not an input and does not disable Register.

3.7.6 Step 5 — Engineering (start-up, run limits, ramp rates)

This step is the plant engineer’s room. Every field on this tab is required. For solar and wind the wizard prefills the worked renewable mapping: start costs and lead times at zero, run limits at zero, ramp rates equal to the suggested MCR. Those N/A fields are shown disabled (muted) with the assumed value still visible — they do not need typing and do not block Register. Hydro does not share that mapping: start-up, run limits, and ramp rates stay editable (a hydro unit has real commitment constraints). For thermal, BESS, hybrid, and anything else the boxes start empty — zeros here are dangerous (§3.8).

Three flags the Code also asks for — energy-constrained, storage, pumped storage — are not on this tab. The wizard assumes they are off. Set them later on Standing data if the plant is hydro, a battery, or pumped storage.

Start-up profile (§7.2(j)) — eleven values, not twelve. Hot and warm each have a threshold (hours off). Cold is every start above the warm threshold, so there is no cold-threshold box.

Run-time limits (§7.2(k)–(l)) — the dangerous-zero pair. A zero is correct for a solar farm and catastrophic for a coal plant: it tells the market the unit may be switched every hour.

Ramp rates (§7.2(m)–(p)) — four numbers, not one. They are not interchangeable. Loading and de-loading decide Instructed Energy on an up-instruction and a down-instruction, so collapsing them into one figure changes money.

Each label shows an i icon; hover it for a short summary of that field.

Certified reserve capacities (§7.2(q)–(t)) are not typed here. They belong to the System Operator. Request them after Register (§3.7.8).

3.7.7 Step 6 — Finance

This step is the one question for your finance team: where settlement receipts land (§7.2(c)). Bank is a card pick of South African banks — each card shows the bank name and its logo, listed alphabetically. The other three boxes start empty. All four are required.

This is the payment destination on the Trading Unit, not the Collateral Reserve or Trading Clearing Account you notify when you join as a BRP (§3.1.6, §3.16).

When every required participant tab is green, Register files the Trading Unit and Point of Delivery through the same path the Market API uses. The wizard then moves to the confirmation step.

3.7.8 After you register — TUID and reserve certification

A green confirmation shows the new Trading Unit id (TUID) and official name. That id is the market’s permanent handle for this plant.

You may then request reserve certification — one button per category the wizard offers:

Each request is sent at the unit’s MCR as the requested megawatts. It does not gate Register — you have already registered. The SO decides on /so/registry (V12 §6). Until certified, those capacities are zero and every reserve availability indicator in a submission is U.

Synchronous Condenser Operation (§7.2(t), MVAr) is the fourth certified category. It is not a button on this confirmation step; request it from the SO registry when the unit needs that carve-out.

Done or Close leaves the wizard. Finish remaining catalogue gaps on Standing data. Modifications take effect under the §7.1(5) 08h00 D−1 rule (deferred when submitted late).

Changing a registered unit — dated, not in place

A registered Trading Unit is not edited in place. Units/Groups (the registry home) and Market › Registry both open an effective-dated modification for MCR, ramps and zone. You name the date the new row starts. Clause 7.1(5) requires the change in writing by 08:00 SAST on the day preceding that date. A request after that cutoff for the next Trading Day is refused and names the cutoff — the console does not silently move the date under you. The API may still schedule D+1; the screen will not.

Pairing a meter after the wizard

The wizard registers a Point of Delivery when it has one. After that, Units/Groups → Registry on the Trading Unit row is where you add, remove or re-pair a meter. An unpaired point is a settlement incident on that card — energy through it cannot be settled for you or the counterparty (§12.3(1)). Removing the last paired point says so; it does not leave a silent empty list.

Trader-pool onboarding will not register one Trading Unit per zone with empty Points of Delivery. It pairs from a signed or active PPA, or it refuses with the remediable reason the register already names. Why that is not “a PPA to join the market”, and what still settles without one: §3.4.

Asking for reserve certification

On Standing data, expand the unit. The reserve board is no longer display-only: Request certification (#reserve-cert-request) starts the SO queue. Certified capacity stays zero until the System Operator decides. Storage units also show the §7.4 storage profile; hydro / energy-constrained units show the §7.3 profile. Internal battery parameters (max cycles per day, degradation cost, minimum spread) are not registry fields.

Uploading a fleet CSV without inventing provenance

Standing data can download the fleet file and upload it back. A value whose provenance column is blank is skipped or refused — the importer never invents where a number came from. That is the same rule the isolated BulkImport helper already enforced.

The standing-data screen is a work list, not a form

After a unit exists, BRP / Market → Standing data is the place you maintain it. The IPPs table lists each registered plant with a Fields count (how many of the thirty §7.2 answers are supplied, for example 30/30) and an Actions view icon — hover for View, to the left of the icon. Click the icon to expand certified reserve capability and the Trading Unit field cards under that row (scroll inside the panel). Click View again to close it. “Eighteen fields missing” tells you nothing you can act on. So the gate says eleven questions for your plant engineer, four for the System Operator, one for your finance team, names each field and the clause that requires it, and says why it is that person’s to answer. That is three phone calls instead of a red form.

3.8 Why zeros are dangerous

Here is the trap, and it is worth understanding before you fill anything in.

“Minimum run time: 0 hours” is correct for a solar farm and catastrophic for a coal plant.

On a solar farm it is true: there is no commitment constraint, the plant follows the sun, and it can stop and start freely. On a coal plant the same entry tells the market the unit can be switched on and off every hour. The market will believe it, schedule it that way, and the plant will fail to follow a schedule it could never have followed — and you pay the imbalance, not the market.

Nothing about the number distinguishes the two cases. A zero looks like a zero. So the platform records, for every field, where the value came from:

0.0 recorded as engineering data registers. The same 0.0 with nobody standing behind it does not. That is the whole mechanism, and it is the reason the screen refuses a blank field instead of defaulting it.

Assumptions are allowed, and they are visible. Refusing to record an assumption does not make it go away — it gets typed in as though it were engineering data, and then nobody knows. So assumed is a valid answer that lets a plant register, and the Market Operator’s console lists every unit that carries one. If a schedule is ever disputed, the assumed field is where the argument will be.

Which capacity number is “the” capacity

One field deserves its own note. Your plant record holds three capacity figures — installed panel capacity, inverter capacity, and export capacity — and §7.2(e) wants exactly one of them: the most the plant can send out continuously.

Export capacity is closest and is not automatically right, because export capacity is sometimes set by a grid-connection agreement rather than by what the plant can actually produce. The platform will not choose for you: it shows all three, says what each one is not, and records which you chose and why. That matters more than it looks — the market requires the top of your price ladder to equal this figure exactly, so a wrong number makes every submission you ever make invalid, silently.

3.9 Compliance nudge (≥ 10 MW)

SAWEM expects generators of 10 MW and up to be balance-responsible. Sites that size without a registered book appear here (and wear a “No BRP” chip on the IPP Sites directory). It is a warning, never a block — the platform nudges; the regulator enforces.

3.9A Bringing a generator site to market

Screen: BRP / Market → Market registry (/org/brp/registry) → Register generator site, or IPP Sites → Register with Market on an unregistered plant (site already chosen).

§7.2 standing data is captured at registration, not invented later. The wizard has one job: turn an operational wheeling generator site into a Trading Unit and Point of Delivery through the same registration path the Market API uses.

Every tab and every input — what it means, required or optional — is in §3.7. This section is the journey around that form.

An unallocatable GPS blocks with the zone-gap notice — the platform does not guess a nearest zone. Register appears only when every required participant field in §3.7 is filled. Reserve certification is requested after registration — it does not gate the button. Gaps the participant is not required to answer stay registerable exactly as §7.1(5)’s register-then-supply sequence intends; finish them on Standing data (/org/brp/standing-data). The same filing is published live to three registers: the participant Standing data tab, the Market Operator IPPs sidebar (/mo/ipps), and the System Operator Registry (/so/registry). Each row shows the plant, the organisation name, the BRP ref when the organisation has one, and how many of the thirty §7.2 fields are supplied. Click the View icon to expand certified reserve and the §7.2 field cards under that row (click again to close). Modifications take effect under the §7.1(5) 08h00 D−1 rule (deferred when submitted late).

Where to go next. Field-by-field wizard (§3.7). The other three seats’ Trading Unit screens (§3.9B). Bid Desk (§4). MO activation (V11 §12). SO registry inbox (V12 §6).

3.9B Trading Unit registration wizards

Three participant seats file a Trading Unit. Each opens a different wizard, because the Code asks a different question of a generator, a consumption site, and a trader pool. The Market Operator does not file units — that seat inspects what the participant already registered.

The BRP cell on Sites and Pools stays blank until the organisation is an ACTIVE Market BRP with a BRP code. A pending application does not unlock Register with Market. On a site that is not in a published network zone the cell says No Market Zone instead of offering the wizard. A trader pool may register in any published zone — member GPS is not a gate.

After a unit exists, Trading Units (/org/trading-units) is the directory: TUID, official name, class, zone, MCR, status, and site or pool. Filters: Zone and Class.

Where this is taught. IPP field meanings and dangerous zeros: §3.7 and §3.8. The generator-site journey: §3.9A. Zone allocation: V12 §2. Site and pool directories: V2 §3, V2 §4, V2 §5.

How every participant wizard is built

All three wizards share the same chrome. The form is a modal over the page you opened it from (it lives inside the page’s main column — it is not a separate route). The overlay dims the board behind it. Nothing is sent until you press Register.

Header. An eyebrow reads SAWEM §7.2 standing data. Under it, the heading in the table above, then a one-line subtitle. Top-right is an X that abandons without filing.

Stepper. Numbered tabs across the top. You can click any tab — the rooms are a corridor, not a locked sequence. The current tab sits on a white chip with a gold ring. A completed room shows a green check. An incomplete room shows its number and a red triangle; hover the tab for a Still needed list of the missing required fields. The stepper is hidden on the confirmation step.

Footer.

Register is not a greyed-out button. It is absent until the stepper is all green. Hover the gold button for a short tooltip of what will be filed. If you somehow submit incomplete, a rose banner says Complete every required field before registering. A refused filing shows Registration refused and the invariant that blocked it.

Required labels carry a red *. Optional labels do not. Several IPP and Off-taker fields have an i icon; hover it for the clause in one sentence.

3.9B.1 IPP — Register generator site

Path: IPP Sites → Register with Market on an unregistered, allocated plant (site already chosen; the Site tab is hidden). Or BRP / Market → Market registry → Register generator site (you pick the plant on step 1).

Subtitle: Prefills from the site, provenance-stamped, one write path.

Register files the Trading Unit and Point of Delivery on the same path the Market API uses. The confirmation is a green panel: Registered {TUID} and the official name. Three buttons then let you request REGULATING, INSTANTANEOUS, and TEN_MINUTE reserve certification at the unit’s MCR. Done / Close leaves. Finish remaining catalogue gaps on Standing data.

Every input — required or optional, what the number means, why a zero is dangerous — is §3.7. Who supplies what, and the three live registers the filing appears on, is §3.9A.

Follow along. Seat: an IPP organisation that is an ACTIVE Market BRP, with an operational generator site. Path: IPP Sites → Register with Market. You should see the §7.2 eyebrow, heading BRP Standing Data IPP Registration, and the Identity tab first.

3.9B.2 Off-taker — demand-side registration

Path: OffTaker Sites → Register with Market on an unregistered site that sits in a published network zone. The site is already chosen — there is no Site picker.

Subtitle: Register this consumption site as a demand-side Trading Unit.

The unit class is DEMAND_SIDE. Generation-catalogue fields the Code still asks for on every Trading Unit are stamped assumed (zeros; ramps equal declared consumption) so the completeness gate that the IPP wizard satisfies with engineering data does not block a load. You do not type those fields here.

Identity

The room opens with Registering {site name} as a demand-side Trading Unit.

Zone

No typed field. The platform allocates from the site’s GPS — never from the Eskom TLF zone on the wheeling record (V12 §2).

Delivery

The meter number is shown as a fact. A rose banner appears if the site has no revenue meter — a demand-side unit cannot be registered until one is attached.

An amber note appears when the site’s municipality has no registered Distributor party. That warning is flagged for Market Operator follow-up and does not disable Register.

Demand

This room never blocks Register. The checkbox is a real choice, not a required tick.

The copy says a Demand Side Unit can respond to a System Operator load-curtailment instruction (§2.1(61)), and that accepting curtailment under a PPA is not the same thing.

Under the label the wizard prints the site’s curtailment acceptance (yes / no) so you can see what the wheeling record already said. That fact does not flip the checkbox for you.

Finance

Same bank-card room as the IPP wizard. All four answers are required.

This is the payment destination on the Trading Unit, not the Collateral Reserve or Trading Clearing Account you notify when you join as a BRP (§3.16).

After you register

A green panel: Registered {TUID} — {official name}. If a System Operator notice was written, the same panel says SO notice recorded. There are no reserve-certification buttons on a demand-side unit. Close leaves. The Sites BRP cell then shows the TUID above the zone swatch; click either to open Trading Units.

Follow along. Seat: OffTaker A (offtaker_a@webill.net) — ACTIVE (BRP-OFFTAKER-A). Path: OffTaker Sites → Register with Market on an allocated site that has no TUID yet. You should see heading BRP Standing Data OffTaker Registration and five tabs: Identity · Zone · Delivery · Demand · Finance.

3.9B.3 Trader — pool registration

Path: Trader Pools → Register with Market on a pool, once the organisation is an ACTIVE Market BRP.

Subtitle: One Trading Unit per selected pool zone (§2.1(212)(a)).

A trader pool is not a meter. The wizard files one MIXED Trading Unit per zone you select, because a unit may not span zones. There is no Delivery tab — the pool is not a plant. Behind Register, meters are copied from signed or active physical PPAs whose member sites sit in that zone. If there is nothing to pair, registration is refused. Long / short is not a registration field. Why a pool still needs those meters, and how an empty MIXED unit is fixed afterwards: §3.4.

The Pools BRP cell shows a count once units exist. Hover the number for each TUID and its colour-coded zone; click the count to open Trading Units. Register with Market stays beside the count until every published zone has a unit.

Identity

The room opens with Registering Trading Units for {pool name}. It previews the official-name pattern: {prefix} · ZN.

Zones

No GPS check. Every published network zone is a card. You may register this pool in any of them.

Register needs at least one newly selected zone. If every published zone is already registered, the step stays incomplete.

Finance

The same four required answers as IPP and Off-taker — bank cards, branch code, account number reference, account holder. One payment destination is copied onto every unit created in this pass.

After you register

A green panel lists every new TUID, comma-separated, and says one Trading Unit per selected zone. Close leaves. The Pools count updates; hover it to see the new TUIDs and zones.

Follow along. Seat: Trader 1 (trader_1@webill.net) — ACTIVE (BRP-T1-DEMO). Path: Trader Pools → Register with Market on a pool that still has unpublished zones. You should see heading Trader Pool Market Trading Unit Registration and three tabs: Identity · Zones · Finance. Select all zones sits above the zone cards.

3.9B.4 Market Operator — no filing wizard

The Market Operator does not open Register with Market. Participants file; this seat sees the units.

Participants → Registrations (/mo/participants). ACTIVE seats only. Columns: BRP REF, Organization (name + status chip), Registered, Trading Units, Actions. The totals line under the table counts registrations and trading units.

The expand table is the party’s registered units — not strategy books:

View on the row still opens the seat drawer (Suspend / Revoke). That is the party, not the unit.

IPPs (/mo/ipps). Generator filings only — the units the IPP wizard created. Columns: IPP / site, Organisation, BRP ref, TUID, MCR, Fields (for example 30/30), Actions. The eye icon expands certified reserve and the §7.2 field cards under that row; click again to close. New filings arrive live. The participant Standing data table works the same way. On /so/registry the eye View opens that IPP on its own page (/so/registry/ipps/{id}) instead of expanding the row.

The Market Operator does not type reserve capacities and does not complete a participant’s Finance tab. Those answers stay with the plant engineer, the finance team, and the System Operator (§3.7, V12 §6).

Follow along. Seat: Market Operator (mo@webill.net). Path: Participants → Registrations. Click a Trading Units count. You should see TUID, official name, class, zone, status, and site or pool — not a Books table. Then IPPs in the sidebar for generator field cards.

3.10 Registration is the boundary of accountability

Your strategy book can forecast and allocate without a market seat. It cannot submit, clear, or receive an imbalance result until the organisation has an ACTIVE registration and the energy sits on a registered Trading Unit. Treat the registration as the legal and financial container; the units are what the clocks see.

3.11 Register Trading Units in the right order

First create or locate the organisation registration and take it to ACTIVE. Register with Market stays locked until then. Then file each Trading Unit from the site or pool it belongs to — not by attaching a book. Confirm the units on Trading Units (/org/trading-units) before the first gate: TUID, class, zone, and status.

1. File the registration while it is PENDING.
2. Work the application board through to ACTIVE (§3.13A) — or, in the demo, use a seat that is already ACTIVE.
3. Return to the registration page and confirm ACTIVE.
4. Open Register with Market on each IPP site, off-taker site, or trader pool that should trade (§3.9B).
5. Confirm the new TUIDs on Trading Units. A Day-ahead submission names the registration and the unit, not a book.

Follow along. Seat: trader_1@webill.net (BRP). Path: Trader Pools → Register with Market on a pool that still has unpublished zones — or Trading Units to see units already filed. You should see: BRP-T1-DEMO, an ACTIVE status chip, and TUID + zone + class — not a book attach table.

3.12 The 10 MW nudge is not an approval

An eligible generator at or above 10 MW can appear in the compliance list without a registered Trading Unit. The No BRP chip says the platform has identified an operational risk; it does not decide regulatory eligibility or stop the site. Resolve it by taking the organisation to ACTIVE and filing Register with Market on that site (§3.9B), then retain the evidence outside this screen where your compliance process requires it.

Careful. Deregistering or suspending a Trading Unit prevents future market clocks from using it. It does not alter completed strategy runs, accepted schedules, or monthly market-file history.

3.13 Joining the market, and how long it takes

Everything above is the platform’s view of a registration. This is the Market Code’s. Becoming a Party — the accession — is a statutory process with deadlines on both sides, and the deadlines are counted in business days — so a five-day clock over a long weekend is a calendar week.

The number everyone asks first: about fifty business days. That is the sum of the four forward clocks — roughly ten calendar weeks — if nobody uses an extension and nobody is late. It is not a target; it is what the Code allows each side, and both sides usually use some of it.

Two things in that table are easy to misread.

Step 2 is a permission, not a promise. The Market Operator may ask for more within ten business days. If it does not, nothing has gone wrong — your application was complete on arrival, and the ten days to issue the agreements start from the day you applied rather than from an answer you never had to give.

Step 6 runs backwards, and it can catch you out even when you are early. The three business days are counted back from the effective date, not forward from anything. Sign on day 2 of your ten and you can still be late, if the effective date is the day after tomorrow. The Market Operator needs those three days to make you live. Your compliance panel shows both dates.

The two agreements

You sign a Market Participation Agreement and a Balancing Agreement. They are not the same document and not the same obligation: one makes you a participant in the day-ahead and intraday markets, the other makes you accountable through the balancing mechanism. A party can be one without the other — a network operator buying its own losses through a designated participant is balance-responsible without ever bidding.

How the console prepares those PDFs, how the Market Operator signs them before you can see them, how you view and countersign them, and how approval becomes activation, is §3.13A · How agreements are issued, viewed and signed.

Asking for more time

Two applicant-owned clocks are extendable on written request, which the Market Operator shall not unreasonably withhold (§6.2(5) clarification response, §6.2(7) agreement return). In the console those states are INFO_REQUESTED and CONTRACTS_ISSUED. Market Operator clocks — including PENDING, INFO_SUBMITTED, and CONTRACTABLE — are not extendable on request; there is no form for them.

How to file a request

Path: BRP / Market → Registration. While one of the extendable clocks is yours and no request is outstanding for it, the Request more time panel appears under Your application:

1. enter how many business days you need beyond the current deadline (1–60);
2. enter the reason for the request (required);
3. submit Request extension.

The console then shows that a request is with the Market Operator. Your Due date on the page has not changed yet.

What the request is — and what it is not

The Code treats an extension as a thing that happened, not a date somebody edited. The platform therefore keeps a record with:

• when you asked;
• the deadline that was in force when you asked;
• how many business days you asked for (and the date that implies);
• your reason.

Three consequences follow:

• the request on its own moves nothing. If you ask on day 19 and hear nothing, you are still on the original deadline — chase the Market Operator’s Extension Requests queue;
• a refusal must give a reason, because “shall not unreasonably withhold” is otherwise untestable;
• submitting the request broadcasts live to any open Market Operator Participants → Extension Requests tab, so the row appears without the clerk refreshing the page.

When you cannot ask again

You cannot file another extension for the same clock while:

A grant is different: after a grant, a later second extension for the same clock is allowed again (extensions can stack under the Code). A decline for INFO_REQUESTED does not permanently bar an extension later if the application moves on and a new extendable clock starts (for example CONTRACTS_ISSUED) — the block is per clock / state, not for the whole application forever.

When the Market Operator decides

You do not need to refresh. An open Registration page receives the decision live:

Until a grant is recorded, quote the original deadline on every call. After a grant, quote the new one — it is the date the daily clock and Pending Clocks both use.

Trading before you are a Party

There is one lawful route: testing and commissioning by agreement with the Market Operator. You may offer energy from plant being commissioned before you accede, and an existing participant may do the same for additional capacity. It is a distinct status, not an early activation — you are not yet a Party, you have no agreement in force, and your volumes are reported distinctly everywhere. That is deliberate: a market notice has to be able to say which megawatt-hours came from plant still under test.

Follow along. Seat: any BRP seat. Path: BRP / Market → Registration → Market Code compliance. You should see your state, whatever clock is running, whose deadline it is, and how many business days are left.

3.13A The application board, step by step

§3.13 is the Code’s version of joining: four clocks and two agreements. This is the console’s version of the same journey. The platform gives the journey fifteen named statuses, so that at any moment you and the Market Operator are looking at the same word for where the application is, and the same date for when it is due.

The statuses refine the Code; they do not replace it. Every period below is one of the Code’s, in business days. Where the Code is specific, the Code wins.

Think of three labels that sit on the same seat and answer three different questions:

Application state is the one you work. The other two are derived from it. That is why this section is organised around the fifteen statuses, not around PENDING → ACTIVE. PENDING → ACTIVE is still the honest answer to may I bid today? — only ACTIVE may. Getting there is the journey below, not a single Market Operator button.

The happy path, in plain words

If nothing is missing and nobody is late, joining looks like this.

1. You file the wizard. The application arrives as pending.
2. The Market Operator either asks a question, or decides the file is complete and marks it contractable.
3. The Market Operator prepares the two agreements, digitally signs both, and only then issues them to you. Until that issue, you cannot see the drafts.
4. You read both on screen and sign them as a pair.
5. The Market Operator approves the signed pack.
6. The Market Operator activates you. On that day you become a Party and may bid.

That is the whole joining story. Everything else in this section is either a detour (more information, a missed deadline, a withdrawal, a decline) or what happens after you are already a Party (suspension, revocation, coming back).

Two screens, one story

You and the Market Operator never share a page. You share a status.

Your page is BRP / Market → Registration (/org/brp). The card is titled Your application. It shows the status, a plain-English explanation, the Due date if a clock is running, whose clock it is, any question the Market Operator asked, files you attached, the agreements once they have been issued, the buttons that are yours, and a History timeline.

The Market Operator’s page for work still in progress is Participants → Pending Clocks (/mo/participants/clocks). Every non-ACTIVE application is a row: party, status, whose move, the deadline. The eye icon opens a drawer. ACTIVE seats live on Participants → Registrations instead — the operational list of who may bid today. Opening View there is read-only for joining; the only buttons left are Suspend and Revoke.

If there is no button on your page, the next step is not yours. The card says so in words: Nothing for you to do — the next move is the Market Operator’s.

What you see on Registration

The Your application card is built the same way in every status. Learn the parts once.

Agreements you have not been issued do not appear. A draft the Market Operator is still signing is invisible to you on purpose.

What the Market Operator sees

Pending Clocks

Path: Participants → Pending Clocks. Columns: Party (code and organisation), State, Whose (Market Operator or applicant), Deadline, and an eye icon (View pending application). An overdue row is tinted rose.

The drawer has four tabs and a sticky Actions strip that stays at the bottom while the details scroll.

Actions are the Market Operator’s lawful next moves for this status — Request information, Mark contractable, Decline, Prepare contracts, Approve, Activate, and so on. If the next move is the applicant’s, the strip says so and offers no button.

Prepare contracts is not a status change. It creates the two PDF drafts. Digitally sign sits on each draft. The application becomes CONTRACTS_ISSUED only after both drafts have been signed by the Market Operator — there is no separate “send” button. Signing the second one issues the pack.

Registrations

Path: Participants → Registrations. This list is ACTIVE seats. Trading Units is the count of registered units on that seat — click the number to expand TUID, official name, class, zone, status, and site or pool (§3.9B.4). View opens the same details / files / history drawer, without Ask and without prepare-or-sign. Suspend and Revoke sit on the sticky footer. Those two buttons change whether the seat may bid today; they are not joining steps.

Where this is taught. Working the Extension Requests queue is V11 §12.5. This section names the clocks that can be extended; that section teaches Grant / Decline.

The four things you can do, and nothing else

Whatever status the application is in, exactly four moves are yours:

Everything else is the Market Operator’s. Showing you a button that would be refused would be worse than showing none.

Every status

A blank period means no clock, and that is deliberate. A timer on ACTIVE would expire a live participant. A timer on WITHDRAWN would expire a decision. Only the seven statuses in the middle of the joining journey have a clock.

Use the table as an index; the notes under it are what each screen actually shows.

PENDING — arrived, being read

The application has been filed. The Market Operator has ten business days in which it may ask for more. Letting those ten days pass is not a breach — the file is then assessed as you sent it (§3.13). The clock never expires this status.

You see. Chip PENDING. Explainer: the application is with the Market Operator. Due counts the ten-day window and says with the Market Operator. No agreements. No files panel unless a later round left some. Buttons: Withdraw only. The card says the next move is theirs.

The Market Operator sees. Pending Clocks row, Whose = Market Operator. Drawer Ask for information is open. Actions: Request information, Mark contractable, Decline. Decline asks for a written reason — that reason is what you will be told.

INFO_REQUESTED — they asked; the clock is yours

The Market Operator has sent a written question. You have twenty business days to answer (clause 6.2(5)). This clock is yours, and it is extendable — Asking for more time. If you do not answer in time, the daily clock moves the application to EXPIRED. Nobody decided against you; the deadline lapsed.

You see. Chip INFO_REQUESTED. The explainer names the twenty days. Due says yours. The Information request block shows their question. Supporting files lets you attach evidence (title required, description optional) and Submit information with a written response. Request more time appears unless a request is already outstanding or was declined for this clock. Withdraw remains.

The Market Operator sees. Whose = applicant. Actions strip: Waiting on the applicant. They can read Files as you attach them. They cannot submit your answer for you.

INFO_SUBMITTED — you answered; they are reviewing

Your answer is in. The Market Operator has ten business days to review it. If that period runs out, the daily clock marks the application contractable anyway — this automatic move favours you.

You see. Chip INFO_SUBMITTED. Explainer: they have ten days; if they do not act, you become contractable. Due is with the Market Operator. The conversation now shows their question and your reply. Files stay visible (view / download; no remove). Buttons: Withdraw only.

The Market Operator sees. Whose = Market Operator. Ask for information is available again if the answer was not enough. Actions: Mark contractable, Decline, Request information.

CONTRACTABLE — ready for the two agreements

Every question has been answered. The Market Operator has one business day to get the agreements out. The drafts are prepared on this status; you still cannot see them.

You see. Chip CONTRACTABLE. Explainer: the agreements will be prepared and issued. Due is with the Market Operator. Your agreements is still empty. Buttons: Withdraw only.

The Market Operator sees. Actions include Prepare contracts (amber) while no drafts exist, then Digitally sign on each draft. Until both are signed, an amber note says Digitally sign both agreements to issue them to the applicant. Decline and Withdraw remain lawful. Issue contracts is not a button you press — signing the second agreement issues the pack and moves the status.

If this one-day clock runs out, the daily job prepares the pair (if needed), signs them as the Market Operator, and issues them — so a clerk who is away for a day does not strand you.

CONTRACTS_ISSUED — the pack is in your hands

Both agreements have been signed by the Market Operator and issued. You have ten business days to sign and return them (clause 6.2(7)). This clock is yours and extendable.

You see. Chip CONTRACTS_ISSUED. Explainer: sign and return within ten business days. Due says yours. Your agreements lists both rows: title, reference, clause, Signed by the Market Operator (name) on date, badge ISSUED, eye icon View. Opening the eye shows the PDF in a large window — read it there; you cannot download it from this page. Sign contracts asks you to confirm that your signature binds the terms on screen. Request more time is available. Withdraw is not offered from here — the lawful exits besides signing are the Market Operator’s.

The Market Operator sees. Whose = applicant. Agreements show MO signature (name and SAST time) and sent date. Actions: Revoke (with a reason). An overdue row is marked overdue — nothing happens automatically. The daily clock does not expire this status. A person decides. An applicant who signs on day eleven is usually given the day.

CONTRACTS_SIGNED — you have signed; they approve

You signed both. The Market Operator has ten business days to approve the pack.

You see. Chip CONTRACTS_SIGNED. Explainer: they have ten days to approve. Due is with the Market Operator. Each agreement now also says and by you on the date you signed, and the badge reads SIGNED. View still opens the PDF. Buttons: Withdraw only.

The Market Operator sees. Applicant signer name with (applicant) and the SAST time. Actions: Approve, Withdraw.

APPROVED — approved; not yet live

The signed pack is approved. Clause 6.2(7) wants three business days between approval and the day you become a Party. On that day the Market Operator activates you.

You see. Chip APPROVED. Explainer: three business days, then you become a Party. Due is with the Market Operator. Agreements stay SIGNED and viewable. No button of yours.

The Market Operator sees. Action: Activate. Pressing it records the written account notification if that tick was still missing, and brings a future effective date forward to the move date, so accession is not blocked by paperwork the clerk is completing in the same step. After Activate, the seat leaves Pending Clocks and appears on Registrations.

ACTIVE — you are a Party

You may trade. There is no clock. The Market Operator may later Suspend or Revoke.

You see. Chip ACTIVE. Explainer: you are a Party and may trade. No Due. Agreements remain viewable. No joining button.

The Market Operator sees. The seat is on Registrations, not Pending Clocks. View is read-only for joining. Footer: Suspend, Revoke.

SUSPENDED — paused, not erased

Participation is paused. Bids already accepted for periods before the effective date still stand (clause 6.4). There is no clock.

You see. Chip SUSPENDED. The explainer says so. No Due. No joining button — coming back from suspension is the Market Operator’s Activate, not your reinstatement request.

The Market Operator sees. On Registrations (or the enforcement queues in V11 §12.5). Actions: Activate (lift the pause) or Revoke.

REVOKED — participation has ended

The seat is finished. Your obligations have not: Required Credit Cover stays in place until every amount is paid (clause 15.10(7)(e)). You may ask to come back.

You see. Chip REVOKED. Button: Request reinstatement.

The Market Operator sees. The seat is no longer an ACTIVE bidder. They wait for your request unless they are working a related enforcement file.

EXPIRED — a deadline lapsed

A clock ran out and the daily job closed the application. This is not a decision against you. You may ask for it to be put back.

You see. Chip EXPIRED. Explainer: nobody decided against you. Buttons: Request reinstatement. (The Market Operator can also Reinstate directly from the drawer when that is the lawful next step.)

The Market Operator sees. Pending Clocks, no running period. They can reinstate, or wait for your request.

WITHDRAWN — you took it back

You ended the application. You may ask to put it back.

You see. Chip WITHDRAWN. Button: Request reinstatement.

The Market Operator sees. Same shape as expired, except the history shows it was your move.

DECLINED — they said no

The Market Operator declined, with a reason. Unlike an expiry, this was a decision. You may still ask to be reinstated on that basis.

You see. Chip DECLINED. The history carries their reason. Button: Request reinstatement.

The Market Operator sees. The reason they typed is on the timeline.

REINSTATE_REQUESTED — you have asked to come back

Your request is with the Market Operator. There is no clock.

You see. Chip REINSTATE_REQUESTED. Explainer: the request is with them. You may still Withdraw the request.

The Market Operator sees. Actions: Reinstate (returns the application to where it had reached), or Withdraw. Activate from here is only lawful if you were ACTIVE before — see Reinstatement.

REINSTATED — a doorway, not a waiting room

The application does not sit here. The platform records the reinstatement and immediately continues to the status the history says it had reached. You will see that earlier status, not REINSTATED, on the next refresh.

Every transition

A transition is one allowed step from one status to the next. The machine refuses anything else — you cannot jump from PENDING to ACTIVE, because that would make a Party with nothing signed.

Who may press the button is fixed by the destination, not by a private list per screen:

• You may move an application to INFO_SUBMITTED, CONTRACTS_SIGNED, WITHDRAWN, or REINSTATE_REQUESTED.
• The daily clock is the only actor that may move an application to EXPIRED.
• The Market Operator may make every other lawful move.

How agreements are issued, viewed and signed

You sign two documents, and they are treated as one pack.

• The Market Participation Agreement is the contract that lets you into the day-ahead and intraday markets — the rules of the auction hall.
• The Balancing Agreement is the contract that makes you accountable through balancing — the till that settles the difference between what you scheduled and what the meters did.

They are not the same obligation. A party can be balance-responsible without ever bidding. In the console they are still issued together, signed together, and effective on the same date (clauses 6.2(6) and 6.2(7)). You will not be asked to sign one and leave the other.

The wizard’s Agreements step (§3.1.6) is the paper trail you typed at filing — references, dates, ticks. The PDFs themselves are created later, on the application board, as follows.

1. Prepare — drafts the Market Operator can see, and you cannot

Once the application is CONTRACTABLE, the Market Operator presses Prepare contracts. The platform writes both PDFs, gives each a reference, and stores them as drafts. On the drawer they appear under Agreements with a Digitally sign button. Your agreements on Registration stays empty. That is the rule: an unsigned draft is not an offer.

2. The Market Operator signs each PDF

Digitally sign on a draft records the Market Operator’s signature on that document and rewrites the PDF so the signature is in the file. The default signatory on the console is Loyiso Mokoena, Authorised signatory, Market Operator, with the date and time in SAST. Signing one of the two leaves the application where it is. The amber note remains until the second is signed.

3. Issue — only after both are signed

When the second draft is signed, the platform issues the pack: each agreement’s status becomes ISSUED, the application moves to CONTRACTS_ISSUED, and Your agreements appears on your page. There is no extra “Send to applicant” click. If the one-day CONTRACTABLE clock runs out first, the daily job does the same work unattended — prepare if needed, sign as the Market Operator, issue.

4. You view, then you sign

On Registration each issued row shows the title, the reference, who signed for the Market Operator and when, the ISSUED badge, and the eye icon. View opens the PDF in a window over the page. Read it there. Close when you are done.

Sign contracts signs both in one action. The default applicant signatory on the console is William Wordsworth, Authorised signatory. After you confirm, both badges become SIGNED, each row adds and by you with the date, and the status becomes CONTRACTS_SIGNED.

Both signatures bind the same terms. If a term changed after the Market Operator signed, your signature would not match and the pack has to be prepared again. That is the protection: you cannot countersign something the Market Operator never saw.

5. Approve, then activate

Approve is the Market Operator accepting the signed pack (APPROVED). Activate is the step that makes you a Party (ACTIVE). Activate also completes the last accession housekeeping: it records that accounts were notified if that tick was still missing, and it will not leave you waiting on an effective date that is still in the future — that date is brought to the day of the move.

Careful. Issued agreements are viewed, not downloaded, on Registration. Treat the on-screen PDF as the document you are signing. The Market Operator can still download supporting files you uploaded; that is evidence, not the contract.

What happens overnight

A job runs once a day, early, before the Market Desk opens. It makes exactly three moves, each only when that status’s period has run out:

Nothing else moves automatically. PENDING never expires: the ten days to ask a question are a window that closes, not a duty they breached. An overdue CONTRACTS_ISSUED is shown as overdue, nothing happens automatically and waits for a person.

Every change reaches you

Each status change sends you a notice with three things: where the application now is, what that means, and what happens next — including the deadline and whose it is.

If the platform cannot reach you, the change is not marked as communicated. It stays on a queue the Market Operator can see, and the daily job retries. A change that was never delivered is visible as undelivered rather than assumed to have arrived.

Reinstatement puts you back where you were

An application that expired, was withdrawn or was declined can be reinstated. It returns to the status it had actually reached, read from its own history, not to the beginning. One that never got past PENDING starts again there, because there is nothing earlier to restore.

REINSTATED is a doorway: the platform logs the reinstatement and continues immediately to that earlier status.

One rule on the way back is worth reading twice: a reinstatement request can only go straight to ACTIVE if you were active before. If you never were, you have never signed the agreements clause 6.2(7) requires, so you are put back where you had reached and you finish the application.

Follow along. Seat: any BRP seat. Path: BRP / Market → Registration → Your application. You should see the status, the plain-English explanation, the deadline and whose it is, your agreements if they have been issued (eye icon, no download), your own buttons, and History. From the MO seat: Participants → Pending Clocks → eye icon, then Details / Files / History / Ask and the sticky Actions. After Activate, the same seat is on Participants → Registrations → View.

3.14 What happens if you get it wrong

Nothing here happens suddenly, and every step has a date you can see.

A Default Notice tells you three things, and it has to: what the default is, how long you have to fix it, and anything else the Market Operator reasonably requires. The remedy time is at least two business days and is often more — your panel shows the date you were actually given and the statutory minimum, so you can see whether you were given extra.

You are still trading while in default. This surprises people in the opposite direction from the rest of this section: a default does not stop you bidding. It cannot, or the remedy period the Code gives you would be worthless.

A suspension order cannot issue until one business day after the notice. And when it issues, it does not bite immediately: it takes effect only after a delay period set by the Market Governance Committee, counted in business days, and different for demand-side units and generators. Between the order and its effective date you are still in the market. Before it bites, the MGC can amend or lift it — for some of your Trading Units and not others.

Two protections are worth knowing by name.

Credit cover. No suspension order may issue solely because your credit cover was absent during a period you were permitted to replenish it, or during the ten business days you are allowed to find a new Credit Cover Provider. Losing a provider is not the same event as being in default. Note solely: if you are also in breach of something else, that other ground is not protected.

Demand. A suspension cannot take effect at all in respect of a demand-side unit unless the Market Governance Committee has directed that the demand at that unit will be met by a Default Retailer. Suspending a load does not stop the load — the electricity keeps flowing and somebody has to be settled for it — so until an alternative supplier is arranged, the suspension is on the file and doing nothing. Your panel and the MO’s board both show that as blocked, with the reason.

Leaving. Termination, voluntary termination and deregistration all end your participation. What they do not end is §3.15.

3.15 Pay now, argue later

The single most surprising rule in the Code, and the one worth reading twice:

Payment obligations continue notwithstanding any query, dispute, shortfall, bad debt, default, suspension, deregistration or termination.

A disputed invoice is still due on its due date. If your dispute succeeds, the correction arrives through a Settlement Rerun — not by the original invoice going away. There is no netting-off while an argument is open, and no grace period for one.

The same principle runs past the exit:

• your Required Credit Cover stays in place until every amount is paid — not until you terminate, which can be months earlier;
• each deregistered Trading Unit keeps its Fixed Credit Requirement until the last Settlement Rerun for the day it was deregistered. That date is not knowable in advance: a rerun can be triggered any time data is revised, so the requirement is released when the last rerun has actually run, never on a timer.

Money stays computable for a party that no longer trades. That is not an oversight in the design; it is the design.

3.16 The three accounts, and which money is yours

When you join the wholesale electricity market, money stops moving directly between you and the people you trade with. It moves through the Market Operator instead. To do that, the Market Operator keeps three bank accounts at one bank — the Market Bank — and all three are in the Market Operator’s own name, not yours. Your money sits inside one of them under a label with your name on it. That is the whole idea, and almost every question about these accounts is really a question about what that label does and does not give you.

They look like one thing with three labels. They are not, and the differences decide what you can do.

Six words you need first

In the Market Operator’s name. The bank’s records show the Market Operator as the account holder. If you telephoned the Market Bank, it would not discuss the account with you. You are not the customer; the Market Operator is.

On trust. The Market Operator holds money that legally belongs to you. Think of a conveyancing attorney holding your deposit while a house sale goes through: it is in their trust account, they control the movements, but it is your money and they cannot spend it on their own business. Two consequences follow: the Market Operator must not mix it with its own money (§15.2(4)), and any interest it earns is yours, because it is interest earned on your money.

Sole name. No trust. The account belongs to the Market Operator outright, and your claim on what is inside it is weaker than in a trust account. This is deliberate for the Collateral Reserve Account, and the next subsection explains why.

Designation. A label inside the account that says which participant a slice of the money belongs to (§15.2(2)). One real bank account, many labels.

First fixed charge. A legal lock. Money under a fixed charge cannot be paid away to anyone until the person holding the charge is satisfied. Comparable to a bond over a house: the house is yours but you cannot sell it and keep the proceeds while the bank’s bond stands. Here the Market Operator holds the charge as trustee for market creditors — meaning it holds the lock on behalf of whoever the market ends up owing money to, not for its own benefit.

Ring-fenced. Walled off. Money in a ring-fenced account may not be reached to cover someone else’s problem, ever, no matter how bad the problem is.

The Trading Clearing Account

The market’s shared current account. Every month, every participant that owes the market pays into it, and every participant the market owes gets paid out of it. Your slice is your designation inside it.

Everyday comparison. The office coffee tin. Everyone who owes for coffee drops money in; the person who bought the beans takes money out. The tin is one tin. Whose money is whose is a matter of the list stuck to the lid, not of separate tins.

Money in: your payment of a market Invoice (a bill from the Market Operator to you). Money out: the Market Operator’s payment of a Self-Billing Invoice — a bill the Market Operator writes on your behalf, to itself, because the market owes you. You do not have to invoice the market; it invoices itself for what it owes you (§2.1(178)). Money out, unhappily: if you default, your balance here can be applied to what you owe.

The account is shared. Your money and every other participant’s money are in the same real bank account. You are not exposed to their trading losses — the designations keep the arithmetic straight — but the timing of the market’s cash does affect you, and the worked month below shows exactly how.

The Collateral Reserve Account

Where the cash part of your security sits. The market will not let you trade on nothing but goodwill: before you can run up a bill, you have to put up something the market can grab if you stop paying. That something is Posted Credit Cover, and it can be either a bank guarantee or cash. The cash goes here.

Everyday comparison. A rental deposit. You paid it, it is your money, the landlord holds it, and you cannot ring up in month six and ask for it back because you are short that month. It comes back when you move out and nothing is owed — not when you would like it.

This is the single most important rule about this account, and it has a one-line justification:

Cover you could withdraw at will would be cover only until the moment it was needed.

The one moment the market needs your deposit is the moment you are in trouble — which is exactly the moment you would want it back. So §15.2.1(5) removes the option. The account is in the Market Operator’s sole name (not on trust), with a first fixed charge in its favour as trustee for market creditors (§15.2(2)). The platform refuses a withdrawal request and names the clause. It still records the request, because a run of withdrawal requests during a cash squeeze tells the Market Operator something worth knowing.

Release is an outcome, never a request. Posted cover is released when the obligations it secures have gone.

If your cover is a guarantee rather than cash, the guarantor is a Credit Cover Provider — see Who can provide credit cover below.

The Market Operator Charge Account

The Market Operator’s own income. It charges fees for running the market, and those fees land here.

Everyday comparison. The shop’s own till, kept separate from the customers’ layby payments. The shopkeeper can spend what is in the till. They cannot dip into layby money — and they cannot be made to put till money into the layby drawer to cover a customer who never came back.

Its balance may never be used to cover a shortfall or a bad debt (§15.3.4(6)). Not “should not”. Never. If it could, the Market Operator’s fee income would quietly be underwriting the market it administers — it would become a participant in the risk it is supposed to referee. So when the cascade in the worked month runs out of money, it does not reach into this account.

You never see inside this account, and nothing you do moves it except paying your MO charges.

A worked month, with real numbers

Everything below is arithmetic you can check. Dates are business days from the gazetted holiday calendar, not counted on fingers. The four parties are a teaching cast for this month — not the demo seats.

Owed to parties = R 1 200 000. Owed by parties = R 1 200 000. It balances, and it must — the market does not create or destroy money, it only moves it between participants.

Why the extra day? The Market Operator must collect before it distributes. It has no money of its own in this loop — it is passing yours along. The one-day gap is the market’s cash-flow buffer, and it is the reason a non-payment hits other participants in the same month rather than the next.

Scenario A — everybody pays.

flowchart LR
  K["Kalahari Trading<br/>pays R 500 000"] --> TCA
  M["Metro Foods<br/>pays R 700 000"] --> TCA
  TCA["Trading Clearing Account<br/>R 1 200 000 in · R 1 200 000 out"]
  TCA --> S["Sunfields Solar<br/>receives R 900 000"]
  TCA --> W["Windgap Wind<br/>receives R 300 000"]

The account ends at zero. That is normal and healthy: it is a pass-through, not a savings account. Nobody’s Collateral Reserve Account moved. The Market Operator Charge Account was not involved.

Scenario B — Metro Foods pays short, and it reaches other people’s money. This is the scenario worth understanding, because it is the only one where your account balance depends on somebody else’s behaviour.

Metro pays R 400 000 instead of R 700 000. It is R 300 000 short. A short payment is not a smaller payment. §15.3.4(2)(d) requires payment in full, without deduction or set-off, so what Metro has actually created is a Shortfall of R 300 000 — whatever Metro believes it is owed on something else.

Step 1 — the tin is short.

Step 2 — call Metro’s deposit. Metro had posted R 250 000 of cash cover in its Collateral Reserve Account. The Market Operator draws all of it. Metro’s deposit is gone. Metro must put it back by 17:00 on Mon 14 Sep — the second working day after the notice (§15.10.2(2)). Until it does, it is short of cover as well as short of cash.

Step 3 — the remaining R 50 000 comes off the creditors, pro rata. This is the debit-note cascade. There is no more money, so the people expecting to be paid are each paid slightly less, in proportion to what they were owed.

R 1 150 000 paid out of R 1 150 000 held. The account closes at zero again.

flowchart LR
  K["Kalahari Trading<br/>owes R 500 000"] -->|"pays in full"| TCA
  M["Metro Foods<br/>owes R 700 000"] -->|"pays R 400 000 — short R 300 000"| TCA
  MCRA["Metro's Collateral<br/>Reserve Account<br/>R 250 000"] -->|"drawn in full"| TCA
  TCA["Trading Clearing Account<br/>holds R 1 150 000<br/>owes out R 1 200 000"]
  TCA -->|"R 862 500 — reduced R 37 500"| S["Sunfields Solar<br/>expected R 900 000"]
  TCA -->|"R 287 500 — reduced R 12 500"| W["Windgap Wind<br/>expected R 300 000"]
  MOCA["MO Charge Account"] -.->|"never — §15.3.4(6)"| TCA

This is how these accounts interact with other traders’ accounts: they interact through the pool. Sunfields did nothing wrong, has no relationship with Metro Foods, and still receives R 37 500 less this month — because it is a creditor of the market, and the market was short. Not a bug; the design. And it is why credit cover exists at all: Metro’s deposit absorbed R 250 000 of the R 300 000 before anybody else felt it.

What did not happen: the Market Operator Charge Account was never touched. Its balance could have covered the R 50 000 comfortably. §15.3.4(6) forbids it.

The follow-up. When Metro pays the R 50 000 late, with interest, the Market Operator credits Sunfields and Windgap back in the next cycle. The cascade is a timing shift, not a write-off — unless Metro never pays, at which point the shortfall becomes an Unsecured Bad Debt and the reduction becomes permanent.

The sharing basis in this picture is what each creditor was owed, so you can see the three accounts move. The Code’s collection basis is actually what each creditor paid into the market that month — two different numbers, which is why a net buyer can owe cash after somebody else defaults. That surprise, and the Excess Participant, is §15.3.

Two more things about accounts.

Before you can accede you must have opened a Collateral Reserve Account or a Trading Clearing Account as required and told the Market Operator in writing. Opening one and saying nothing does not satisfy the requirement, and accession is blocked until the notification is on file — not reminded about afterwards. A live participant with no account produces an invoice with nowhere to charge it.

Not the same as a Trading Unit’s payment destination. The bank details on a Trading Unit are where you want your settlement receipts sent, and they are per unit because different units can have different funders. The three accounts above are party-level and in the Market Operator’s name. The difference between them is the difference between money held on trust and money paid away.

Where the money actually is, and how you move it

§3.16 explains what the three accounts are. This is how you use them on the platform: two screens, and two kinds of movement you start yourself.

Two buttons that move money: Add funds, and Pay

Both sit on Your money, next to your own-bank balance. They are easy to confuse and they are not the same transaction.

Add funds is a deposit into your own bank account. It is money arriving from your own business. It has nothing to do with the market. Your own-bank statement labels it that way so it can never be mistaken for market income. The market accounts do not move. You press it when the operating balance is too low to post cover or pay an invoice.

Pay is a deposit into the Collateral Reserve Account — cash credit cover, under your BRP designation (BRP-…/COLLATERAL_RESERVE). It leaves your own bank account and lands in the market’s Collateral Reserve, labelled as yours. Once posted it cannot be withdrawn on request (§15.2.1(5)). The confirmation box says so before you press the button. On the Market Operator’s board the same movement appears under Recent deposits, with your BRP code and designation.

A third movement you start yourself is Pay by EFT on an invoice. That is a payment, not a deposit: it leaves your own bank account and lands in the account the invoice names.

Every one of those is an EFT (§15.2(7)). There is no other payment method. And none of them can exceed the balance in your own bank account. The amount field is capped at that balance; submitting more is refused and nothing moves. An account that could go negative would be inventing money.

The organisation screen — Market Accounts

Path: Market Accounts (/org/market-accounts) → Your money. The sidebar item sits under Configuration.

Your own bank account is the only account that is really yours. It opens with R3 000 000 when your registration is created, because you need funds before you can post cover or pay a first invoice. It is not one of the three §15 accounts. The card shows the name, the masked number, the balance, and any amount already instructed but not yet settled. Add funds and Pay sit on the right. If you are short of what you owe the market, a warning appears here — before the due date, not at 12:00 when it is too late.

Invoices and payments due. Each outstanding document shows its kind, reference, status, what is still owed, and Pay by EFT. A trading invoice pays into Trading Clearing. A Market Operator Charge — the monthly fee the Market Operator sets on its own Accounts screen — pays into the MO Charge Account. An unpaid MO charge is not a Shortfall: it does not draw your cover and it does not cascade onto other participants.

Tick Automatic EFT for the monthly Market Operator fee if you want that invoice paid the moment it arrives, from your own bank account, provided the balance covers it in full. If you cannot afford it, the invoice stays and you pay it by hand after Add funds.

Three things the screen does that are worth knowing about in advance:

• It tells you if you cannot afford a trading invoice, before the due date.
• It will not let you overdraw. A payment larger than your own-bank balance is refused.
• It lets you pay a trading invoice short, and warns you what that means. Paying short is not a smaller payment. §15.3.4(2)(d) requires payment in full, so the balance becomes a Shortfall: your posted cover is drawn, and any remaining gap comes off other participants’ receipts. The confirmation box says so before you press the button.

Your slices of the market’s accounts. Two cards — Trading Clearing and Collateral Reserve — with your designation and your balance. You do not have your own Trading Clearing Account; you have a designation inside the market’s one. The Collateral Reserve card carries the warning that you cannot withdraw it. You never see inside the Market Operator Charge Account. Its fees appear on your statement as deductions from Clearing, labelled Market Operator fees.

Your statement. Two of them, both expandable. Statement lists every movement in and out of your designations, each with a sentence explaining it. Your own bank statement lists your own account with a running balance, like an ordinary bank statement.

The line that matters most. If a month ever comes where you are paid less than your Self-Billing Invoice, your statement carries two lines: what you were paid, and a reduction that says why — “the market collected less than it owed, and you were 75 % of the creditors that cycle”. You did nothing wrong; somebody else did not pay, their cover did not cover it, and §15.3.4 spreads the rest across the creditors in proportion. Being told which and by how much is the difference between a dispute and an explanation.

Follow along. Seat: any BRP seat. Path: Market Accounts (/org/market-accounts) → Your money. You should see your own bank account with Add funds and Pay, two cards for Trading Clearing and Collateral Reserve, the automatic-EFT tick for the monthly fee, and any outstanding invoices with Pay by EFT. Open Pay, enter an amount no larger than your balance, and confirm: the Collateral Reserve card updates under your BRP designation. Add funds only raises your own-bank balance.

The Market Operator screen — Accounts

Path: Accounts (/mo/accounts). This is the other side of every movement above.

The reconciliation line is first, because it can invalidate everything below it. Each of the three accounts must have a bank balance equal to the sum of the designations inside it. When they agree, the line says so. When they do not, it names the account and the difference — a money event has written one layer and not the other.

The three account cards. Trading Clearing, Collateral Reserve, and the MO Charge Account. Each shows the bank balance, the designated total, and — where money sits — every BRP designation and its slice. The MO Charge Account is marked ring-fenced: its balance may never be applied to a shortfall (§15.3.4(6)).

View transactions on each card opens that account’s bank statement: date, what happened, amount, running balance. A Pay on the organisation screen appears here as a credit-cover deposit on the Collateral Reserve. A Pay by EFT on a trading invoice appears on Trading Clearing. A monthly fee appears on the MO Charge Account.

Recent deposits lists cash cover as it arrives — date, BRP, designation, amount — so a posting on Market Accounts is visible here without a refresh.

The monthly tariff lives on the MO Charge Account card. Set the amount in rand and press Save and charge this month: every ACTIVE organisation is issued a Market Operator Charge invoice for that amount. Issue this month’s invoices bills anyone not yet charged this period, without changing the tariff. Organisations that have automatic EFT on, and that can afford it, are paid at once into this account; the rest stay outstanding on their Market Accounts screen.

Cash position is this billing month: expected in, received, the gap, and what is still to be paid out. That is the number that decides whether a cascade is needed. Who cannot pay lists participants whose own-bank balance is already short of what they owe — before the due date. If a cascade is needed, the board says so and reminds itself that the MO Charge Account is not available for one.

Follow along (Market Operator). Path: Accounts (/mo/accounts). Confirm the reconciliation line is green, open View transactions on Collateral Reserve after a participant has pressed Pay, and find their BRP on Recent deposits. On the MO Charge Account card, set a monthly tariff (for example R 5 000) and Save and charge this month. Then, as that organisation, open Market Accounts and find the Market Operator Charge invoice.

Who can provide credit cover

A Credit Cover Provider must be a bank holding a South African banking licence, or an international bank authorised to provide banking services in South Africa. Nothing else qualifies — not a parent-company guarantee, not an insurer, however well capitalised. Credit cover has to be callable on demand by the Market Operator on the day the participant it covers has stopped paying, and a guarantee from an entity with no banking authorisation is a promise that has to be litigated at exactly that moment.

If your provider withdraws, you have ten business days to appoint another, and no suspension order may issue solely because cover is absent in that window.

Where this is taught. V3 teaches book structure and risk limits. V21 teaches seed, worker and operational recovery procedures.

Data. full_demo · seed 42 · stage S08 (market loop) · registration example BRP-T1-DEMO for T1 Industrial Pool.

4. The Bid Desk

Screen: Bid Desk (/org/brp/bid-desk). Daily is the front door. Submissions, IDM, Forward, Settlement and Imbalance share a Trading Day and a Trading Unit. DAM and IDM bids for registered books still live here: build, submit, watch clearing, drill provenance. Settlement and Imbalance are Bid Desk rooms for the delivered day (V10 §12.6, V10 §12.7). The Billing Period wallet is Market Month (V10 §13). The organisation screen map for this desk is V10 §12. The Market Operator reads the same day on Bidding (/mo/bidding) — V11 §12.7. Do not look for a sidebar item named Bidding on this seat.

4.1 From run to net position

The bridge from book to market is the hourly net position. Read the latest completed strategy run (NOMINATED if fresh for the trading day, else FORECAST). For each SAST hour:

net (MWh) = Σ spill (long, +)  −  Σ shortfall (short, −)

Decomposition is kept — each component carries the opportunity cost strategy already computed (V3).

Worked example — hour 12 (canonical BidBuilder demo). Two spill lines: firm take-or-pay 5.00 MWh (spill value 0) and wind 1.71 MWh (spill value 40 c/kWh). Net: +6.71 MWh long, decomposed as [firm 5.00 @ 0c, wind 1.71 @ 40c].

A P90 evening hour: firm-demand shortfall 6.0 MWh, Eskom top-up 210 c/kWh. Net: −6.0 MWh short.

Provenance: unit-test / BidBuilder worked ladder (same numbers as M6 gate narrative). Not a sealed-DB statement line — re-run the Bid Desk against your book for live figures.

4.2 The bid ladder

Never sell below what the energy is already worth to you; never pay more than the gap would otherwise cost — then apply the safety margin. Markets quote R/MWh (1 c/kWh = R 10/MWh).

The ladder is how this desk prices rungs. What the Market Operator stores and clears is the curve on a Submission — §4.8.

Hour 12 ladder. Firm: 0 × 10 + 10 → 5.00 MW @ R 10/MWh. Wind: 400 + 10 → 1.71 MW @ R 410/MWh. Short evening: 210 × 10 − 10 → 6.0 MW limit R 2 090/MWh.

Open-position clamp. If the book has an OPEN_POSITION_MW risk limit (V4 risk limits), no hour may exceed it. Excess is dropped; every clamp is logged as a clip on the Bid Desk.

The forecast provenance popover includes the latest day-ahead nMAE, measured P90 coverage, and paired-hour count. A missing row says no scorecard. Open the plant’s Forecast page for the weekly source comparison and XML packs. The chip is evidence for the trader’s judgement; it adds no automated bid gate.

4.3 Clearing and DAM uplift

SAWEM is blind, uniform-price: offers clear when rung ≤ SMP, buys when limit ≥ SMP — everything trades at SMP, not at your bid.

At hour 12 with prototype SMP R 980/MWh, both rungs clear:

revenue        = 6.71 × 980           = R 6 575.80
counterfactual = 1.71 MWh @ 40 c/kWh  = R   684.00
DAM uplift     = 6 575.80 − 684       = R 5 891.80

That uplift is what the MARKET dashboard panel accumulates. The R 980 hour is the desk demo (BidBuilder canonical ladder). The Code price on the golden day is R 900 at 18:00 — §4.12.

Bid status: DRAFT → SUBMITTED → ACCEPTED / PARTIAL / REJECTED / EXPIRED. Past the DAM gate without submit → EXPIRED + critical gate-miss alert. A rollover is not a sixth status on this desk: it is the Market Operator writing a Submission from your last accepted horizon (§4.10).

4.4 Cross-book netting

When one registration balances several books, the market settles the registration, not each book. Long and short books in the same hour are netted; only the residual is bid. Component ladders merge — prices are never blended; attribution keeps each book truthful at SMP.

Hour 12: trader +6.71 MWh, IPP −2.00 MWh → netted +4.71 MWh one OFFER. Revenue 4.71 × 980 = R 4 615.80 equals the gross trade at SMP. What you gain is execution risk and open-position headroom (8.71 → 4.71 MW on the Bid Desk badge).

4.5 What you do on the screen

Open Bid Desk → Submissions. Pick a Trading Unit (the TUID is in the URL when you arrive from a Daily unit action — the first-registered unit is not a silent default). The live object is a 168-period WB.Sawem.Submission. A line that has not left the desk shows the banner: This draft has not been sent. Review the automation level in Controls to see whether the worker may send it. You have two ways the same payload leaves this desk:

1. Automatic. Under AUTO_WITHIN_LIMITS, SubmitDamBids runs at 03:00 SAST on D−1 and, after the participant checks, PUTs the Submission to /api/v1 (WB.Brp.MarketClient.put_submission/4). You do not have to sit here at three in the morning.
2. Manual. Submit on this screen calls that same HTTP path — the object Validate already checked. Use it when you rebuilt after 03:00, or when you want the payload on the wire before the worker.

If curve emission fails, Submit refuses and says why. There is one write path. The Market Operator clears the Submission, not a book ladder.

A line that has not left the desk is DRAFT. After Submit it is SUBMITTED. The gate countdown on the ribbon is our clock, not your browser’s — if the laptop is four minutes fast the desk shows the skew rather than quietly trusting either one.

After 12:00 FetchSchedule fills accepted volumes and the System Marginal Price. Open the line drawer for provenance — strategy run, members, opportunity costs. The curve the Market Operator actually cleared is on their Bidding → Submissions drawer, not as 168 editable periods on this desk.

IDM lives on the same desk (§5). Imbalance after delivery: §6.

4.6 Worked ladder — preserve why every rung exists

You need to know whether a line is a sale of a genuine leftover or a bid whose economics were guessed. The desk answers that with a rung per long component and a provenance drawer per rung.

Data. full_demo · seed 42 · stage S08 (market loop) · BidBuilder canonical ladder, re-derived 2026-07-18.

Start with the conversion: R/MWh = c/kWh × 10. Firm energy is 0 × 10 + 10 = R 10/MWh, so it offers 5.00 MW at R 10. Wind is 40 × 10 + 10 = R 410/MWh, so it offers 1.71 MW at R 410. The short hour has one buy limit: 210 × 10 − 10 = R 2,090/MWh for 6.00 MW.

At an SMP of R 980/MWh, both offer rungs clear. The market revenue is 6.71 × 980 = R 6,575.80. Wind’s counterfactual is 1.71 × 400 = R 684; its market uplift is R 6,575.80 − R 684 = R 5,891.80. Conservation is 5.00 + 1.71 = 6.71 MWh = cleared volume ✓.

4.7 Netting, clips and statuses

Netting happens before a market order, but attribution remains per book. A trader long 6.71 MWh and an IPP short 2.00 MWh produce +6.71 − 2.00 = +4.71 MWh. The registration submits 4.71 MWh; its market value is 4.71 × 980 = R 4,615.80. Attribution remains R 6,575.80 for the trader and −R 1,960 for the IPP, therefore R 6,575.80 − R 1,960 = R 4,615.80 ✓.

If an open-position cap clips a line, the clip is evidence that the desk did not silently submit the entire run. Open Rebuild from latest run after a strategy refresh, inspect every clip, then submit.

Follow along. Seat: trader_1@webill.net (BRP). Path: Bid Desk → Submissions → Rebuild from latest run → review the draft banner and ladder → Submit. You should see: the Gate countdown, a draft-not-sent banner, a rung drawer with source run and component values, and a submitted status before 10:00 SAST.

EXPIRED is your status. If you never pressed Submit, the ladder dies on this desk. Rollover is the Market Operator’s act — they generate a Submission from day 2…7 of your last accepted horizon. You will see a rolled-over badge on their board, not a red alarm. §4.17.

4.8 What you are actually submitting

The desk still shows rungs and provenance so you can see why a volume was priced. That is a local explanation. The market object is the Submission. Submit and the 03:00 worker emit curves with BidBuilder.build_curves/4 and PUT them to /api/v1. The Market Operator clears that Submission. The counterpart who opens Bidding → Submissions sees it: 168 structured periods, consent, curves, energy limits. This desk does not draw those 168 periods as an editor.

A real submission is not a price and a volume. It is, for every hour of the next seven days:

• how much you can produce in that hour — your Declared Available Capacity;
• a price ladder for it, expressed as a five-block curve rather than a list of rungs;
• whether the market may move you — one character, and the most consequential one on the form;
• whether you are offering reserve in each of three categories.

Seven days, 168 hours, every one of them declared. Tomorrow is the one that clears at the gate; the six behind it are how the market sees you coming.

The five blocks

The curve is not five prices for five products. It is one rising cost curve for the same megawatt-hour, cut at four points you nominate:

Mingen and E3 are locked on the desk. They come from your registered standing data, not from the submission form, and the two most common rejections in any electricity market are a curve whose bottom does not match the registry’s Mingen and one whose third elbow does not match its MCR. On this desk you cannot author either mistake — the fields render read-only with the registry value in them. If the number is wrong, the registry is where you fix it, and the fix is effective-dated.

The blocks may be zero-width, and usually are. A solar farm submits Mingen = E1 = E2 = 0 with E3 = MCR: four empty blocks and one real one. That is not a degenerate case to be worked around, it is the shape every renewable submits, and the desk accepts it without comment.

You are paid the hourly price, not your block price

This is the part that surprises people. The prices in your curve decide whether you are scheduled and how much of you is scheduled. They do not decide what you are paid.

Whichever blocks clear, every megawatt-hour is settled at the System Marginal Price for that hour — one price, the same for everyone. If your must-run block is priced at R350 and the hour clears at R900, that block earns R900. Your curve is a statement about your costs so the market can stack you correctly. It is not an invoice.

The consequence worth internalising: pricing a block low does not mean being paid less for it. It means being scheduled sooner. Pricing it high does not earn more; it risks not running.

4.9 The flexible indicator

One character per hour. F or I. It is the most consequential single character on the form, and it is routinely set without thought because it looks like a checkbox.

I is a commitment, not a ceiling. This is the misreading, and it costs money. I does not mean at most this much. It means the market will schedule you at precisely the figure you declared, and you are then obliged to deliver it.

Work it through for a solar farm. At 09:00 the desk shows tomorrow’s 18:00 hour and your forecast says 40 MW. Declare 40 MW / I and you have not capped yourself at 40 — you have promised 40. If the cloud arrives you are short against an instructed position, and the shortfall settles against you in the balancing mechanism at whatever the imbalance price turns out to be. Nobody instructed you to be short; you declared a number and the market believed you.

What you get in exchange is that an inflexible offer cannot set the System Marginal Price. The market had no choice about you, so your price is not the marginal one. For a non-dispatchable unit that could never have set the price anyway, that is no loss at all — which is why I is the honest declaration for a unit that genuinely cannot be moved, and a bad one for a forecast.

The trade is real in both directions: F accepts being moved in exchange for the chance to be the price setter; I buys certainty of volume at the cost of being unable to influence what it is paid.

4.10 Missing the gate is not the end of the day

The DAM gate closes at 10:00 SAST on the day before delivery. Miss it and the desk does not leave you with nothing. The Market Operator generates a rolled-over submission on your behalf.

The rule is simple and worth knowing exactly, because it decides what you are committed to:

Day 1 of the rollover is day 2 of your last submission, day 2 is day 3, and so on. Day 7 repeats day 7 — there is no day 8 to shift from.

In plain terms: we re-use yesterday’s plan, shifted a day. Everything you declared for the day after tomorrow becomes what you have declared for tomorrow. Your energy limits shift with it, on the same rule. You will be notified every time this happens; a rollover is never silent.

The gate clock on the desk is the server’s, not your browser’s. It renders the Market Operator’s own instant, and if your machine’s clock disagrees the desk shows you the skew rather than quietly trusting either one. A gate decision made against a laptop running four minutes fast is a gate decision made against nothing.

Why a week of misses is a real problem

Roll forward once and you are submitting a plan that was a day old. Roll forward seven times and every day of your horizon is the same day-7 profile, repeated — the fixed point the rule converges to. Nothing is broken, no submission is rejected, and you are declaring a week-old profile as your intent for next Tuesday.

That is why the desk carries staleness as a number (staleness_days) and not just a badge. Each rollover increments it, the unit shows it, and crossing the threshold raises an alert rather than continuing quietly. A unit that has rolled over four days running is not having a quiet week; it has stopped participating and nobody has noticed.

The next chance to change the plan after a missed DAM gate is the first IDM iteration that still covers the hour (§5.1) — a patch, not a new bid. You cannot re-price.

4.11 Pre-flight, and one implementation of the rules

The desk’s Validate action runs the full submission code set — every structural, curve, indicator, energy-limit and storage rule — and reports the result as a checklist, each failure with its clause and what to do about it. Run it before you commit.

It matters that this is the same code the API’s dry run and the real submission call. A pre-flight check that reimplements the rules in the browser drifts from the server’s, and the drift shows up in exactly one place: a participant told its submission was clean, and rejected at 09:59.

A 409 (gate closed) or a refused horizon is not lost. The Market Operator sees it on Bidding → Submissions (#submissions-rejected) — the intake audit — and can tell you “we have your 409”. See V11 §12.7.

Follow along. Seat: trader_1@webill.net (BRP). Path: Bid Desk → Submissions → pick a Trading Unit → day selector → Validate. You should see: 24 rows for the selected day with DAC, the flexible indicator and three reserve indicators; Mingen and E3 read-only in the curve editor; the server gate clock with its countdown; and a clean checklist before you submit.

4.12 What happens after the gate

The gate closes at 10:00 and the market runs an auction. Not a negotiation, not a queue — a single clearing that looks at every submission at once.

Sellers are stacked cheapest first. Buyers are stacked most-willing-first. The auction walks up one stack and down the other until they cross, and the volume up to that crossing point trades.

Use the worked hour. Five Trading Units, 18:00:

Demand is 440 MW of distributor load that cannot be shed, plus a factory drawing 90 MW of which 40 MW is must-serve and the rest it has priced. The stacks cross inside rung 6, with the coal plant at 435 MW.

Everybody who cleared trades at R900. The plant that offered R350 for its first 200 MW is paid R900 for them. The solar farm that offered R0 is paid R900. The factory pays R900 for every megawatt-hour it drew, including the blocks it valued at R4 800.

That is not a quirk; it is the whole design. Your offer decides whether you clear and how much of you clears. It does not decide what you are paid. Pricing a block low means being scheduled sooner, not being paid less — which is why the honest thing to offer is what the energy actually costs you.

The 14:00 publication is a chalkboard. Energy money (EPM) is calculated immediately and paid with the month. Do not treat the schedule report as a deposit.

4.13 Why the price is sometimes lower than the most expensive plant running

At 19:00 the sun is down, the distributor is drawing 520 MW, and the market is tight. The coal plant runs to its full 500 MW, the gas peaker is started at its minimum of 60 MW, and the factory is curtailed from 90 MW down to 60.

The most expensive plant running is the peaker at R2 800/MWh. The price is not R2 800.

A plant held at its minimum cannot set the price. The peaker cannot run at 50 MW — it runs at 60 or not at all. The market did not choose to buy its sixtieth megawatt-hour; it chose to start the unit, and the minimum came with it. An offer the market had no choice about is not a marginal offer.

The same applies in three other situations, and they are worth recognising because each one means your offer was not price-setting that hour:

The last two are properties of the clearing, not of your submission. You cannot tell from your own schedule that a ramp bound — which is why the schedule tells you (see §4.15).

If every unit is inflexible in a period, the price is zero. Not the highest inflexible price: zero. An hour in which nothing flexible ran has no marginal cost to reveal.

The one we have decided and the market has not

At that 19:00 hour, the genuinely marginal resource is the factory choosing not to consume. It shed a block it valued at R2 600/MWh. Economically that is the value of energy in that hour, and it is what a sixth megawatt-hour would have been worth to somebody.

The Market Code is written in generation vocabulary and never says whether a partially-curtailed load may be the price setter. The two readings differ by R1 700/MWh in that single hour.

We treat the factory as price-setting. It is the economically correct reading: under the other one, scarcity is invisible in the price — the market says R900 while a customer is switching off machines it valued at R2 600. But the rule is not settled, the Market Governance Committee has not decided, and every clearing we publish records what the price would have been under the other reading so the divergence is measured rather than argued about. You will see it on the console as [D-08].

4.14 Two schedules, and why

Every Trading Day is cleared twice. Zones do not set the price.

Daily (/org/brp/bid-desk) shows the hourly forecast and a unit’s published schedules in Details & destinations. Bid Desk › Settlement (/org/brp/after-delivery) retains the detailed schedule view. Unpublished results and missing forecast hours remain visibly different from zero.

Where this is taught. The overview, chart and evidence drawer are in V10 §12.2.

The unconstrained schedule ignores the network. It is the market’s answer to “what is the cheapest way to meet this demand?” — and it is the one that sets the price and the one your energy payment is struck on.

The constrained schedule adds the System Operator’s security limits: this corridor cannot carry more than so many megawatts, this zone cannot export past a cap. It is the one the system is actually run from.

Where they differ, you are compensated separately — at your own offered price, not at the market price, and the cost goes to the System Operator rather than to other participants.

Work the worked day again. The solar farm clears at 75 MW unconstrained. The System Operator caps exports from its zone at 60, so the constrained schedule cuts it to 60 and lifts the coal plant from 435 to 450.

Fifteen megawatt-hours it never produced, at R900 each. That is not a bug in our implementation; it is what the Market Code says, and it follows from the charge being struck at the unit’s own offered price — which for a renewable offering at zero is zero. The chalkboard writes that as CSC R 0.00 with the sentence zero-priced curve, not as a blank cell.

Two consequences worth internalising, because they point in opposite directions:

• Being curtailed by the System Operator is free. The compensation is struck at your own offer.
• Re-declaring your own capacity down is not. That is an intraday decision and it is charged at the intraday price. §5 covers it.

A participant who re-declares defensively when a constraint was coming anyway pays for the privilege.

4.15 Reserve prices sit at their floor most of the time

Alongside the energy price, four reserve prices are published every period: Regulating Up, Regulating Down, Instantaneous and Ten-Minute.

They are usually at their floor, and the board says so with an at floor badge. That is not a fault and not a placeholder — it is the normal state of an uncongested hour, and here is why.

A unit holding back capacity for reserve gives up the profit it would have made selling that energy. That forgone profit is market price − the unit's own cost. When the unit holding the reserve is also the unit setting the price, those two are the same number and the difference is zero. So the price falls back to the floor the Market Governance Committee published.

What lifts a reserve price off its floor is a plant whose own cost is below the market price, held back to stand ready. A unit costing R400 in a market clearing at R900 gives up R500 for every megawatt it holds — and that R500 is what the reserve is worth that hour.

So an at-floor reserve price tells you something real: nobody was holding back anything valuable. A reserve price above its floor tells you the system was leaning on plant that could profitably have been generating.

4.16 Reading your own schedule

The Bid Desk shows your day-ahead schedule once the Market Operator publishes it — by 14:00 on the day before delivery.

Both volumes are there, side by side, and every period says why it landed where it did: at your declared capacity, at your minimum, ramp-bound, held by down-regulation, or cut by a network constraint — each as a sentence rather than a code.

That is deliberate. The System Operator is obliged to explain a dispatch instruction if you ask. Putting the reason on the schedule means you do not have to ask, and it saves a query on the days the answer is “your ramp rate bound at 18:00”.

A binding constraint is named as a sentence on the constrained volume (“export cap on this zone”), not as a code. When the constrained-off volume settles at your own offer of R 0, the line is CSC R 0.00 — that is data, not a missing charge.

Where this is taught. V3 owns run construction and component economics. V8 §7 owns contract adjustment pricing after metering.

4.17 Three doors into a Submission

A Submission reaches the Market Operator through one of three doors. Who may use them: the registration is ACTIVE, the Trading Unit is not suspended, and a unit still in commissioning may submit only where the Code allows a commissioning bid.

You do not pick the door on this desk. Auto and manual Submit share door 1. Door 3 is never a BRP button.

Data. full_demo · seed 42 · Trading Day 2026-07-15 · hour 18:00 · SAWEM-SPEC §10 / market-dam.md §11.

4.18 The consumption curve

A load does not offer cost stairs. It states what the energy is worth — willingness to pay — and a block the market may not shed at any price.

The factory on the golden hour wants 90 MW: 40 must-serve, then 10 at R4 800, 20 at R2 600, 20 at R1 500. When the system is tight the last blocks go first.

4.19 Energy limits are not the sum of the dailies

A hydro or a battery can be honest about every hour and still be lying about the week. The hour says 80 MW; the reservoir cannot release 80 × 168.

Energy limits sit on the horizon, not on the sum of the twenty-four daily caps. The Market Operator validates them as a reservoir: what you declared across the seven days cannot exceed what you said you have. If the daily figures add to more than the limit, the payload is refused — the hours were each legal and the week was not.

Where this is taught. Field catalogue stays in this chapter. The Market Operator’s read-only drawer is V11 §12.7. IDM cannot rewrite these limits (§5.9).

4.20 Bid Desk — Daily and the destination rooms

The jobs used to share one scrolling page. They now have addresses. The sidebar still says Bid Desk. Daily is the front door. Submissions, IDM, Forward, Settlement and Imbalance share a Trading Day and a Trading Unit. The Billing Period wallet is Market Month (sidebar After Delivery — V10 §13). A Balancing Group never totals EPM.

Deep links keep the date: /org/brp/bid-desk/submissions?date=2026-07-15, /org/brp/bid-desk/idm?date=2026-07-15&iteration=4, /org/brp/after-delivery?date=2026-07-15.

You cannot edit a Mingen or an MCR from this desk. Those are registry fields. You change a curve by sending a new sequence.

4.21 Operate 2026-07-15 from the stall

Data. full_demo · seed 42 · Trading Day 2026-07-15 · hour 18:00 · org-dam.md §15 / §16.7.

Seat: trader_1@webill.net / supersecret.

1. Open Bid Desk → Submissions with ?date=2026-07-15. Find the draft banner if a ladder has not left the desk.
2. Submit, or leave it for the 03:00 worker. Do not invent a 24-period body.
3. Open Daily. Every owned Trading Unit has a row. Missing filters the units without a submission.
4. After publication, open Settlement. Read unconstrained 75 MWh against constrained 60 MWh. The CSC line that reads R 0.00 must carry the own-offer sentence.
5. Open IDM. Decide carry versus re-declare before the next gate. The book table is this platform’s ledger.

Follow along. Seat: trader_1@webill.net (BRP). Path: Bid Desk → Submissions (?date=2026-07-15) → Daily → Settlement → IDM. You should see: a draft or a sent seq, unit rows, a chalkboard that is not an invoice, and five iteration chips.

4.15 Participant trading checks

New registrations start at PROPOSE. The worker builds a draft for review; it does not submit it. MANUAL also retains the draft. AUTO_WITHIN_LIMITS permits worker submission after all six participant checks. The demo estate opts into that level explicitly. Raising a level requires an independent active member’s approval; lowering it applies immediately.

Before transport, each attempt records capability, price collar, daily Rand notional, line count, duplicate content, and the named book OPEN_POSITION_MW check. A refusal leaves the draft available for correction. A member must explicitly accept soft warnings before retrying. The automatic path records soft warnings in the audit. VaR and counterparty limits remain alert-only.

Capability uses declared MCR, then the effective MEC limit, site export capacity, or a configured MW cap. The initial tolerance is 0%. The initial forecast collar is P10–P90 ±20%, bounded by the market floor and cap. Missing forecast evidence produces a warning while market bounds still apply. Manual lines have no builder exemptions. The Controls tab labels derived values; onboarding includes entering the customer’s daily Rand cap.

For a 75 MW connection, offers of 60 MW at R480 and 900 MW at R950 total 960 MW and are refused. With P10 R612 and P90 R1,190, the lower bound is R489.60 and upper bound R1,428. The notional is R883,800; the derived daily cap at a R5,396.40 market cap is R9,713,520. Correcting the offers to 60 MW at R490 and 9 MW at R950 passes these bounds.

An unsubmitted PROPOSE draft is escalated at gate minus 30 minutes. The alert never submits it. See the Controls tab and Approvals inbox.

5. Intraday and IDM

Contracted battery reserve lines

A battery’s bilateral reserve commitment specifies MW, direction, sustain duration, active hours and a capacity price. It is honoured by the battery plan before the IDM decision reads the net position. UP reserves discharge power and stored energy; DOWN reserves charging power and empty storage. BOTH does both. Reserve power is never added to energy available for sale.

A 2 MW commitment for four hours at R220/MW/h creates four zero-kWh BESS_RESERVE capacity lines worth R1,760 in total. This revenue contributes to total margin and is shown separately to the owner. It is not energy delivery or a reserve-market clearing result. Activations use the existing System Operator instruction path to correct state of charge and replan the remaining hours; the unchanged day-ahead plan remains available for comparison.

Reserve-market clearing remains behind backlog item 4. This commitment register records a bilateral product; it does not claim that the platform runs a reserve auction.

Screen: Bid Desk → IDM tab (/org/brp/bid-desk).

The day-ahead market locks a schedule the day before. Weather and load still move. The intraday market lets you re-declare what your plant will do for hours not yet delivered — and it charges you for the privilege in a way the day-ahead market does not.

5.1 Five auctions, at fixed times

There is no rolling window. The intraday market runs five auctions a Trading Day, at times that do not move:

A re-declaration applies to each remaining hour. Iteration 5 closes at 18:00, so it can move 19:00 and cannot move 18:00 — the hour whose delivery is beginning as the gate shuts — let alone anything earlier.

The desk shows all five with a countdown, and the countdown comes from our clock, not your browser’s. A laptop four minutes fast would otherwise show you four minutes you do not have, and the gate you miss is real. Selecting an iteration chip loads that iteration’s lodgements and the carry / re-declare decision — the chips are not cosmetic. There is no rolling T−60 window; the worker rings these five Code gates only.

Your day-ahead submission carries over automatically into every iteration: price curves, technical parameters, availability. A re-declaration is a patch, never a replacement — you change your Declared Available Capacity or your declared consumption, and everything else stands. You cannot re-price mid-day. If you could, you could watch the intraday stack form and then move the price you are about to be paid at.

5.2 Changing your own mind costs money; being moved does not

This is the section to read twice.

When the System Operator moves you off your schedule, you are compensated at your own offered price — which for a renewable offering at zero is nothing, and you keep the full day-ahead payment (§13.4). Being constrained off at a zero offer is free. Re-declaring is not.

When you re-declare your own capacity down, that is charged at the Intra-Day Price, flat. Your own offer buys you nothing. The IDM tab shows the IdmDecision (carry or re-declare) before you lodge; a submit that cannot show that decision is refused. Consent is a separate control — changing it does not silently re-declare volume. The worker writes a TUID re-declaration, not a book-level :IDM bid.

Follow along. The worked delivery day, 18:00 period. Heavy cloud arrives at 11:30 and the solar farm re-declares from 60 MW to 20 MW before the 12:00 gate.

Σ check: 67,500 − 0 − 37,800 = 29,700 — the farm keeps R 29,700 for the 20 MWh it actually generates, an effective R 1,485/MWh against a market price of R900. Still favourable, and only because the System Operator’s curtailment was free while its own re-declaration was not.

Turn it round and the lesson is sharper. Had the System Operator constrained all 55 MWh instead, the farm would have kept the whole R 67,500 and paid nothing.

Careful. If a constraint is coming anyway, re-declaring first transfers value away from you. The desk’s recommendation (§5.5) exists for exactly this decision.

The same clause runs the other way for the units that pick up the slack. The coal plant lifted 450 → 465 MWh and the factory curtailed 90 → 65 MWh were moved, not volunteers: they are on instruction, and they keep the better of their own offer and the Intra-Day Price.

5.3 We tell you before you commit

Enter a re-declaration on the desk and, before you submit it, the screen tells you how it will be classified and what that means for the price:

PURCHASE_AGAINST_INSTRUCTION · clause 10(6)(i) This is against instruction. 40.000 MWh will be charged flat at the Intra-Day Price for this iteration — not at your own offered price.

The classification is certain, not a guess. The Market Code decides it from your declaration, not from what the market later does, so it can be stated before the auction runs. The price is the estimate, and it is labelled as one. The most useful API field on that preview is estimated_classification — it is what the desk is showing you.

A single hour can carry both: raise your capacity by 10 MW, get scheduled up by 15 MWh, and 10 of it is against instruction while the other 5 is on. The preview says so rather than picking one.

5.4 The intraday price is capped near the day-ahead price

Every iteration produces its own price per period, and it is held within ±5 % of that period’s day-ahead System Marginal Price.

The worked day’s iteration 4 is a good example of why that matters. The units the market moved offered R900, R1 500 and R2 600 for the megawatt-hours it took, which averages R1 412.50. The cap pulls it back to R945.00 — 5 % above the day-ahead R900. That clamp is [D-03]: the Code’s lower-bound wording is misdrafted, so both the indicative average and the applied collar are published (§17).

The desk shows you both numbers with a collared badge, so you can see when the cap moved the price and by how much. Rendering only the capped figure would hide that the market wanted a different answer.

Two smaller rules worth knowing. Only the movements the Market Operator chose set the price — a participant that re-declares its own capacity does not get to drag the price it will then be charged at. And where the iteration’s changes net to nothing, the intraday price simply is the day-ahead price.

5.5 Carry it, or re-declare it?

The platform used to re-bid any hour that drifted a megawatt-hour from schedule. Under SAWEM that rule is wrong, and wrong in the expensive direction. The desk now walks IdmDecision in order: instruction → band → compare IDP vs balancing.

The desk now compares.

The band is a percentage of your contracted position, not a fixed megawatt-hour figure — a 500 MWh unit and a 20 MWh unit have very different room.

Note. The recommendation comes with its reason on screen. “Carry” means three different things in the table above, and which one applies decides what changes if your forecast moves again.

5.6 Reversals: you do not pay twice for changing your mind twice

If a later iteration undoes an earlier one, the earlier charge is given back for the part that was undone. In the worked day the cloud thins at 18:00 and the farm goes back from 20 MW to 40 MW: half the 40 MWh it re-declared away is restored, so half the R 37,800 comes back.

That netting reaches all the way back — past iteration 1, to the day-ahead constrained adjustment itself. A unit returned to exactly the schedule the day-ahead market gave it has a net intraday position of R 0.00, whatever route it took to get there. Back to the DAM constrained schedule ⇒ net IDM R 0.00.

5.7 Contracted Energy is what balancing measures you against

Your Contracted Energy is the schedule from the most recent iteration plus any registered forward volume for that Trading Period — not the day-ahead residual alone. It is what every balancing deviation is measured against once the day is delivered, and the desk and the API both publish it per period.

If nothing was re-declared, it is the day-ahead constrained residual plus the forward base. If iteration 4 moved you, it is iteration 4’s residual plus the same base, and iteration 5’s after that. The forward base does not change between iterations; only the residual does.

5.8 Let instructions win

An instruction changes what the asset is allowed to do. If a curtailment, outage or dispatch constraint applies, investigate that instruction before building an intraday correction. The desk can show the condition; it never turns an instruction into commercial advice.

Careful. A closed gate and an instruction-blocked interval are different facts. The first leaves a normal market deviation; the second may produce an instructed, excusable one once the System Operator’s evidence is present.

Where this is taught. V3 owns forecast and allocation runs. V12 §3.2 owns instruction treatment; §13 owns the day-ahead money the intraday market adjusts; V8 §11 owns reruns and post-metering correction.

Data. full_demo · seed 42 · Trading Day 2026-07-15 · hour 18:00 · SAWEM-SPEC §10 / market-dam.md §11.

5.9 What the IDM does not change

An IDM iteration patches remaining hours. It does not rewrite the day-ahead auction.

The IDM has its own price (IDP) and its own charge (IDC). Those sit beside the chalkboard, not inside it.

5.10 On the MO Bidding IDM tab

The Market Operator does not lodge your patch. They watch the five auctions on Bidding → IDM (/mo/bidding/idm). The stack they see is anonymised — prices and volumes, no TUID. Your name is on the lodgements table, not on the stairs.

The teaching home for that console is V11 §12.7.

5.11 On the Bid Desk IDM tab

Your patch is lodged from Bid Desk → IDM (/org/brp/bid-desk/idm), not from the Market Operator’s stack. Five iteration chips keep the date. The classification preview is certain before you commit; the price is an estimate. When nothing was lodged, the table says so — it does not draw zeroes.

The five-tab map is §4.20. The Market Operator’s anonymised stack stays in §5.10.

6. Imbalance

Screen: Bid Desk › Imbalance (/org/brp/after-delivery/imbalance) — a Bid Desk room for one Trading Day and one Trading Unit (V10 §12.7). Deep links carry ?date= and ?tuid=. The headline is the eleven §13 legs per Trading Unit (#balancing-statement), loaded from the same GET /balancing/trading-units/:tuid/:date surface the Market Operator publishes. This platform’s book figure, if shown, is labelled book actual − scheduled and is not §13. A mismatch between the book and the statement is shown as a variance, not silently preferred. Metering exceptions sit on the same tab (#allocation-exceptions-view) with the vintage stamped on them. Month › Balancing equals the sum of published §13 statements for that Trading Unit, or “no statement”.

After delivery the market compares what you contracted for with what your meters actually did, hour by hour, and settles the difference. There is no single “imbalance price”. Market Code §13 asks a short series of questions about each hour, and the answers decide both the volume you are charged on and the price it is struck at.

This chapter walks the questions in the order the Code asks them.

What changed. Until MS11 this platform priced a single number: the whole deviation, at a short or surplus price. §13 has eleven payment legs, two balancing prices, a 5 % tolerance that an instruction removes, and a complete override for Balancing Groups. Your imbalance figures have changed materially, in both directions. §6.8 says how, and what it means for the risk limits you set in V3.

6.1 The three quantities

Everything in §13 is written over three numbers for each Trading Unit and each Trading Period.

AE needs a Point of Delivery with two named BRPs. An unpaired meter, or a unit with no meters, does not rewrite SE or the day-ahead energy payment. The two tills are §3.4.

All three are signed: positive is produced, negative is consumed. A load contracted at −65 MWh that consumed 66 is short — in exactly the same direction as a generator that under-produced by 1 MWh.

The one that surprises people is SE. If the intra-day market moved your schedule at 12:00, your deviation is measured against the moved schedule, not against what you sold the day before. DAM EPM is not recalculated here.

6.2 The decision tree

Ask these in order.

Did the System Operator tell you to do something?

Yes — that part of your movement is settled at your own offer price, and your 5 % allowance no longer applies to anything in that hour.

No — are you within 5 % of your contract?

Yes — you settle at the day-ahead price (the System Marginal Price). No penalty.

No — the whole deviation, not just the part beyond the 5 %, is priced at the balancing price.

Two of those branches are worth stating twice, because they are where money actually moves.

An instruction removes the 5 % tolerance entirely. The tolerance is called the Metering Accuracy Band and it exists for metering error on a position you scheduled yourself. It is not a free allowance against a dispatch instruction. If the SO instructed you in an hour, the band does not exist in that hour — for any part of your deviation, instructed or not.

Missing the band is a cliff, not a slope. Miss by 4.9 % and you pay the day-ahead price on the shortfall. Miss by 5.1 % and you pay the balancing price on everything.

The same instruction that made IDM say carry (§5.5) is the instruction that removes the band here. Do not re-declare an hour the System Operator already owns, then argue the band on the imbalance screen.

6.3 The cliff, with numbers

You contracted for 20 MWh and nobody instructed you. Your 5 % allowance is 1 MWh, so anything from 19.000 to 21.000 MWh is inside the band.

Six hundred kilowatt-hours more shortfall costs R3 304.29 more — because it did not merely add volume, it moved the price basis. The 0.9 MWh that used to settle at R900 now settles at R2 742.86 along with everything else.

The Imbalance screen shows this as a counterfactual whenever you breach the band: what the same deviation would have cost inside it, and the difference. If you are routinely a few hundred kilowatt-hours outside, that panel is the cheapest thing on the screen to act on.

6.4 Where the balancing price comes from

The balancing price is not a multiple of the SMP. The Market Operator builds a merit order — the Balancing Energy Sold stack — out of every flexible, available unit’s submitted offer curve, and averages it over however much energy the market as a whole was short in that hour.

Two consequences you should plan around.

It is a market-wide price, not yours. You are 1.5 MWh short; the price you pay was computed over the market’s shortfall, which in the worked hour is 3.734 MWh across four units.

It can be enormous. In a tight evening hour, with the sun down and a cheap unit already at full output, the marginal balancing energy is a factory choosing not to consume at R2 600/MWh and a gas turbine at R3 100. The average comes out at R2 742.86/MWh against energy that was worth R900. A BRP 10 MWh short in that hour pays R27 428.60 for energy worth R9 000 — 3.05 times.

That is the mechanism that punishes optimistic forecasting.

6.5 And it can be zero

Now the uncomfortable part.

Clause 13.7(2) excludes the most expensive part of the stack, up to a parameter called Out of Merit Energy. Annexure 2 sets that parameter at 2 000 MW. In a comfortable hour the whole available balancing stack can be smaller than 2 000 MW — in the worked example it is 160 MW — so the exclusion removes everything, there is nothing left to average, and the rule that floors the price at the SMP becomes the whole answer.

The Balancing Price (Buying) equals the System Marginal Price. The penalty vanishes. A participant that missed its schedule by 7.5 % pays exactly what the energy was worth, which is no penalty at all.

We do not hide this. When it happens:

• the Imbalance screen shows the price with its reason — the stack volume, the volume excluded, and the clause — rather than a bare figure that happens to equal the SMP;
• the Market Operator console raises a market-integrity alarm for the period;
• the public price API publishes the same diagnostics alongside the price.

On the real national system the sold stack is tens of gigawatts and the 2 000 MW exclusion bites only at the tail. In any sub-market, island, simulation or early-market condition it removes the balancing penalty entirely. We are raising this with the market governance committee, together with the related observation that the Market Code defines a “Balancing Penalty Factor” — apparently to guarantee a minimum penalty — and then uses it in no formula at all. Both are implemented as parameters so the answer can be adopted without a code change.

6.6 If you were instructed

An instruction changes the shape of the settlement, not just the size.

The part of your movement that follows the instruction is settled at your own submitted offer curve, floored at the SMP if you sold and capped at it if you bought back. That is usually favourable: you offered that price, and the market took you at it.

Two details worth knowing.

You are paid for what you delivered, not what you were told. The Code’s published formula integrates up to Instructed Energy, which would pay you for energy you never generated. We integrate to what you actually delivered, capped at what was instructed. In the worked hour that is R8 100.00 rather than R9 210.94 — and the leg on your statement says which basis was used and why.

There is a gap the Code does not price. If you beat your contract but missed your instruction — you were told 475 MWh, you were contracted for 465, and you delivered 474 — the difference falls between two clauses and no clause reaches it. We do not invent a charge for it. We report it: your statement shows 1.234 MWh unpriced with the clause reference. That number is the evidence we are putting behind a Modification Proposal.

6.7 Balancing Groups, and why they are worth having

Think of two pockets in the same pair of trousers. One pocket has R8 too much. The other is R8 short. You are the same person. You did not lose R8 — you moved it from one pocket to the other. The market, left to itself, does not see the trousers. It sees two pockets, bills each one, and you pay a penalty on both.

A Balancing Group is you asking the market to look at the trousers.

What you are grouping

A Trading Unit is the bundle the market schedules and settles — usually one per network zone, because a unit may not span two zones. After the hour, the market compares three numbers for each unit (§6.1):

Each unit also has a 5 % band (§6.2): a small tolerance for metering error. Stay inside it and you settle at the day-ahead price — the System Marginal Price (SMP). Step outside it and the whole deviation is priced at a harsher balancing price. Missing the band is a cliff, not a slope (§6.3).

If you never ask for a group, each unit walks that cliff alone. Being long in one zone does not cancel being short in another.

Who sets it up — and who does not

You do. The BRP that owns the units designates them. Market Code §13.10(1). It is a request, not a default. Two rules:

1. At least two Trading Units (§2.1(21)). One unit has nothing to net against.
2. All yours. You cannot put another party’s unit in your group.

The Market Operator does not create the group for you. The System Operator does not approve it. The SO’s power is the opposite: it can take the benefit away for a congested zone — that is the catch below.

On this platform you designate the group on Trading Units (/org/trading-units): select the units, Group these units, name it, set the window, designate. The Market API (POST /api/v1/registry/participants/:mpid/balancing-groups) does the same act for a machine. BRP / Market → Market registry (/org/brp/registry) shows the groups you have already designated — name, member TUIDs, dates, status, and a cover forecast for the next Trading Day. The forecast is an expectation: it uses the scheduled position as a direction proxy because actuals do not exist yet, and it labels itself as such. How to ask, and what a group is not, is also §3.6.

A Balancing Group is not a trader pool (your commercial book), not a Trading Unit (what is scheduled), and not the Balancing Agreement you signed to join the market.

A worked hour — why the group is worth having

Same trader, one hour, nobody instructed. Prices are the ones this chapter already uses: SMP R900.00/MWh, selling balancing price R500.00/MWh, buying balancing price R2 742.86/MWh (§6.3).

Step 1 — each unit’s own 5 % band.

• Solar: 5 % of 20 MWh = 1 MWh. An 8 MWh miss is far outside.
• Load: 5 % of 100 MWh = 5 MWh. An 8 MWh miss is outside.

Both units have fallen off the cliff. Without a group, each is priced at the balancing price on all 8 MWh, not just the bit past the band.

Step 2 — ungrouped money (two pockets).

• Solar is long, so the market buys the extra 8 MWh from you at the selling balancing price: 8 × R500.00 = +R4 000.00.
• Load is short, so you buy 8 MWh from the market at the buying balancing price: 8 × R2 742.86 = −R21 942.88.

Net: −R17 942.88. The extra solar and the extra factory use cancelled in the real world. The prices did not cancel, because selling-balancing and buying-balancing are different numbers. You paid a penalty for being the same person in two zones.

Step 3 — grouped (the trousers).

Add the two promises, then add the two meters:

• Group contracted: 20 produced − 100 consumed = 80 MWh net consumption.
• Group actual: 28 produced − 108 consumed = 80 MWh net consumption.
• Group deviation: 0.

The 5 % band is now asked of the group. Zero is inside any band. §13 stops asking “did this unit miss?” and starts asking “did this group miss?”

Each member still settles its own 8 MWh — but at the SMP, which is what the energy was worth that hour:

• Solar: 8 × R900.00 = +R7 200.00
• Load: 8 × R900.00 = −R7 200.00
• Net: R0.00

No penalty exists anywhere in that settlement. The two halves are the same price, so they cancel.

That is the strongest argument in the Market Code for putting a whole portfolio under one BRP and then designating the units. You set a group up when you hold several units whose misses tend to offset — a trader with generation in one zone and load in another is the usual case.

The catch — the trousers can lose a pocket for an hour

The System Operator can flag a zone’s exports or imports as full (§3.3(6)): the wires cannot take any more out, or cannot take any more in. Then §13.10(2) does not switch the whole group off. It drops only the members who are making that jam worse, and only in the hours the flag covers.

Think of a one-lane bridge at rush hour. The group is a car-pool sticker. If the bridge is jammed outward, the officer pulls out the passenger who is pushing more traffic onto the bridge — a generator that produced above schedule, or a factory that used less than scheduled (both send extra energy out of the zone). The passenger who is relieving the jam stays in the car. A unit exactly on schedule is never pulled out: there is no direction to a miss of nothing.

The other way round if the zone cannot import.

This is checked hour by hour. The group can be intact at 14:00 and broken at 18:00.

Same numbers, catch applied. The SO flags Z1 (the solar zone) as export-constrained in this hour. The solar unit produced 8 MWh above schedule — that is extra energy leaving Z1 — so it is excluded. The load in Z6 stays. There is no group left to net against.

The solar unit is now alone (and long). The load is now alone (and short, outside its 5 % band). You are back on the ungrouped line: −R17 942.88. The relief you counted on vanished in the hour the network was tight — which is usually the hour you most wanted it.

So the benefit is real, and it is contingent. Treat the group in V3 as a scenario, not as an assumption in every hour. The group view on the Imbalance screen shows every exclusion with its reason and its clause. A member silently dropped would look like a bug.

The cover forecast on Market registry is the answer to this warning before the hour: for the next Trading Day it names, per period, which members are expected to be excluded given the flags in force. It is labelled an expectation, not a settled result — actuals do not exist yet. If a Z1 member is out between 17:00 and 20:00 tomorrow, that is where you see it.

Careful. Designating the group does not move energy across a congested boundary. It only changes how the market prices mismatches that already cancelled inside your portfolio — and only while the wires can take it.

6.8 Preliminary and official

Balancing prices are calculated after the fact. A preliminary figure is published by 17:00 on the day after the Trading Day, from provisional metering. The official figure lands on day seven, once metering is verified and the dispatch instruction log is verified with it.

They are different numbers and both stay on the platform. The preliminary one is what you plan against; the official one is what you are invoiced on. A dispute does not hold either up — the Code requires payment first and argument after, and an adjudicated correction arrives later as a Settlement Rerun, which records a new figure rather than erasing the one you were invoiced.

The screen labels every figure with its stage and the metering vintage behind it. If you export imbalance data, export the label with it.

6.9 What the screen shows

Per Trading Period:

1. The three quantities — contracted, instructed, actual — and the deviation.
2. Whether an instruction applied, and if so which clause removed your 5 % band.
3. The band allowance, and the counterfactual if you breached it.
4. The System Marginal Price and both balancing prices, with diagnostics if either is degenerate.
5. Every leg: its clause, the volume, the price basis and the amount.
6. Any unpriced volume, with its clause.
7. For a grouped unit: the group’s netting, the response allocated to each member, and any exclusion.

Two rules the screen keeps in front of you:

1. Imbalance is per hour. A perfect month with one bad afternoon still pays for that afternoon — and if that afternoon was a tight hour, it pays three times over.
2. It is attributable. Drill into the legs before you argue with the MO file (§8).

PPA settlement vs balancing. Contract settlement (V4) prices delivered energy under your PPA. Balancing is the wholesale settlement of schedule error. They share meters; they are not the same ledger.

Follow along. Seat: trader_1@webill.net (BRP). Path: BRP / Market → Imbalance → choose delivery date → open a Trading Period. You should see the three quantities, the band status, both balancing prices with diagnostics, and every leg with its clause.

The Market Operator does not re-price imbalance on Bidding. The MO stack is the anonymised Balancing desk (/mo/balancing) — both prices, the [D-07] alarm, preliminary vs official. This screen (/org/brp/imbalance) is where the organisation reads its own legs. The two views are the same run seen twice; they are not two models.