V15 · Billing

1. This volume — bills, invoices, and who is asking to be paid

Settlement told you what the month added up to. This volume is about what happens next: someone issues a document, someone receives it, and both sides can find it again.

That is the one sentence that separates this volume from V8 · Settlement: settlement decides the numbers, billing turns them into documents.

Where this is taught. The ledger, the pipeline, and the statement as evidence live in V8. Come back here when the question is “who invoices whom, under what number, and where do I find it?”

The problem this volume solves

A month on this platform produces many money movements: energy on a PPA, use-of-system charged by a network operator, a WER credit, a market invoice from the Market Operator. Those movements already exist as ledger lines that sum to zero. What did not exist, until this programme, is the document a finance clerk can file, a VAT return can cite, or a counterparty can pay against.

You were looking at a VAT column that always read zero next to a label that said “15%”. That is the defect this volume opens on — and the reason chapter 3 exists before any invoice is issued.

The two sides

Every document has two seats, and one organization can sit in both in the same month.

The same row is both things. Issuance writes it once; delivery is the recipient seeing that row.

How to read this volume

The chapters follow the month, not the org chart.

1. Words and tax — what a bill is, what a tax invoice is, how VAT is computed (§2, §3).
2. Who may issue — the five issuer kinds, mandates, the grain election that stops a supply appearing on two tax invoices (§4).
3. Identity of a document — gapless numbers, stored artifacts, copies, retention (§5).
4. The run — what happens on the 1st, what preflight refuses, when a period is solid enough to invoice against (§6).
5. The documents themselves — per-entity, consolidated, the registers, then the receiver-side site view and hub (§7–§12).
6. Special issuers — Eskom and municipalities, the Market Operator (§14 is started — Invoice versus Self-Billing Invoice and the two clocks), virtual PPAs (§13–§15).
7. Money after issue — payments, corrections, analysis, one worked month (§16–§19).

Follow along. Seat: OffTaker C (offtaker_c@webill.net) or the Eskom door (eskom@webill.net). Path: after you can see a settled month in V8 §12, the VAT column on the running ledger is the first billing figure you can trust. Documents come in later chapters.

2. Bill, statement, invoice — three words that are not interchangeable

You have been handed three pieces of paper that all have a rand figure on them, and someone has called each of them “the bill”. They are not the same document. Mixing them up is how a supply ends up with two tax invoices, or how a clerk files a statement as if it were an input VAT claim.

Where this is taught. How the numbers on a statement are decided — V8. Who may put a tax invoice in front of a counterparty — §4. Where you search for one you issued — §9.

The problem

A month on this platform produces evidence, a reading of the month, and a legal claim. Those three things look similar in a browser. They are not interchangeable at the Receiver of Revenue, and they are not interchangeable when a counterparty asks which document do I pay?

The three words

A statement proves a number. It is settlement evidence: the ledger lines for a period, frozen, hashed, and (once the month run has finished) sitting under a stored PDF. You use it to answer “how did we get this figure?” You do not pay a statement. You do not claim VAT on one.

A bill tells you what happened this month and who to pay. It is the reading: the six charge groups, the counterparties, the net position. The site view and the organisation roll-ups are bills in this sense. They span suppliers. That is why they can never be a tax invoice.

A tax invoice is the legal document one supplier issues to one customer for one supply. It has a gapless number, a legal block on both sides, a VAT total that was computed from the rate in force, and a stored artifact whose hash does not change when you download it twice. That is the document a finance clerk files and a VAT return cites.

The platform keeps one row for that tax invoice. The issuer sees it in the issued register. The recipient sees the same row in received records. Issuance writes both; there is no second system that has to agree.

Why the site view is not a tax invoice — and why that is a feature

A site’s month touches more than one supplier. Eskom bills use of system. A generator bills energy. A municipality may bill a wheeling charge. If the site view were allowed to be the tax invoice, that one supply would carry two (or three) legal documents, and neither issuer could defend its number.

The grain election in §4 is the same idea at the organisation layer: either the per-entity document is the tax invoice and the org roll-up is a pro-forma annexure, or the other way around. The platform refuses a second tax invoice over a source reference that is already covered. That refusal is a data rule, not a review comment.

Note. A credit note is the document you get instead of a corrected invoice once the original has been delivered. It references the tax invoice; it does not replace its number, and it does not consume the one-tax-invoice-per-supply slot. Before delivery, a mistake is a new version that supersedes the draft or undelivered issue. After delivery, it is a note. The boundary is received_at.

3. VAT and rounding — the figure that used to be a label

The finance clerk’s problem is simple: the statement showed a VAT line and a “15%” label, and the cents were always zero. That was not a rounding error. The ledger was written with vat_cents: 0 on every line, and the renderer printed a constant next to the sum of those zeros. The label made the zero look like a computation.

VAT is now computed. This chapter is how.

How a line gets its VAT

1. The period has a date. The platform looks up the VAT rate in force for that date in the jurisdiction (today: ZA, 15% from 1 April 2018). A period that straddles a rate change uses one rate — the period’s own date — and records which row it used.
2. The line has a treatment: standard, zero-rated, exempt, or out of scope. Treatment comes from the charge category, unless the line itself carries an override (a CfD line is the case that needs one — it shares the :energy category with ordinary PPA energy).
3. Standard-rated lines take VAT on the absolute rand amount and then put the line’s sign back on the cents. A receivable of R 292,410.00 at 15% is vat_cents: 4,386,150. The matching payable is the exact negative. That is why a credit note and its invoice cancel to the cent.
4. Zero-rated, exempt, and out-of-scope lines store vat_cents: 0 and vat_applicable: false. That is distinguishable from the old silent zero, which stored vat_applicable: true over a zero.

Rounding is half-up at two decimal places, the same rule the market uses for money (WB.Sawem.Rounding). It is applied once, when the cents become a line — not in the middle of a formula.

Document denomination

Every document, invoice, treasury account and settlement statement carries a currency — the ISO 4217 denomination of its integer minor units. The platform’s documents are Rand documents: the default is "ZAR", and a write path that never mentions currency still produces a ZAR row. The denomination is fixed at issue. Changing it would be a re-denominated invoice, which is a new document, not an edit.

Currency is not a dimension of identity. One subject, one period, one kind — in one currency. Putting the code into the identity tuple would let the same supply be billed twice in two currencies.

A line whose currency differs from its document is refused at the changeset. Mixed-currency arithmetic without a published rate is refused by name. Conversion is a later, explicit step against the FX register; it is not implied here. See V18 for why this fact had to land before the pool could be traded.

The four treatments, in plain words

Two treatments are interim until tax counsel answers them: WER / WEPS credits and nomination-shortfall compensation, CfD settlement flows, and REC / carbon certificate lines. All currently compute as standard, under a named constant, so a change of opinion is a data change plus a failing test — not a rewrite of the engine.

Where this is taught. Certificate lines themselves — V19 §11.

Why a credit note’s VAT cancels its invoice

Every ledger movement is a pair. The IPP’s energy receivable and the off-taker’s energy payable are the same cents with opposite signs. VAT is taken on the absolute amount and then signed. So:

IPP energy     +R 292,410.00    VAT +R 43,861.50
Off-taker      −R 292,410.00    VAT −R 43,861.50
               ─────────────        ────────────
Σ              R 0.00               R 0.00

If those two VAT figures ever differed by a cent, a set of issued documents would be unreconcilable, and an issued document cannot be quietly edited. It can only be credit-noted. That is why the suite asserts Σ vat_cents == 0 across a full period, including the eight worked examples in the physical settlement book.

A document total does not sum the line VAT figures. It recomputes VAT from the sum of amounts in each rate bucket, half-up once. That stops a document drifting from its own lines by a rounding cent.

What you see

On the running ledger (V8 §12.4) the VAT column is now the tax on the lines, and the net is exclusive of VAT. The CSV export’s vat_cents column matches the screen to the cent. On a statement the VAT label is the rate that was actually used for that period, or the words rate not configured if none was in force — never a printed “15%” over a zero.

Careful. VAT figures shown for months settled before this release were structurally zero. Historical statements are not restated. A statement is evidence of what was calculated at the time; rewriting it would invent a second truth. New runs compute VAT. Old runs keep the zero they stored.

Where this is taught. The ledger pairs themselves — V8 §8.

4. Who issues what — five kinds, one supply, one invoice

The finance clerk’s question is who is asking to be paid? Settlement already answered how much. This chapter names the five seats that may put a tax invoice or a credit note in front of a counterparty, and the three ways the platform is allowed to produce that document.

Where this is taught. The ledger pairs themselves — V8 §8. Grain and numbering — §5.

The five issuing capacities

An issuer is not “an organisation”. It is an issuing capacity: Eskom acting as network operator; a municipality doing the same; a trader pool in its selling role; a generator site selling energy; or the Market Operator. One organisation can sit on both sides of a month — a generator org issues energy invoices and receives Eskom use-of-system invoices.

Buyers are not issuers. Money they are owed arrives as the counterparty issuer’s credit note. Every ledger pair already has one payee; that payee’s side is the issuer’s side.

What “issuing capacity” means when you both issue and receive

The same legal entity can be Eskom-the-operator (issuing UoS invoices) and Eskom-the-BRP (receiving a Market Operator remittance). Those are two hats, one legal block, two number series. The operator portal will show issued wheeling documents and received market remittances side by side. Until that portal lands (MU1), the identity is stored so the run can name the party — Eskom, a municipality, and the VWP vendor no longer appear on the ledger as party_id: nil.

The three mandates

The platform can produce a document in an issuer’s name only when the mandate that authorises it is on file.

PLATFORM_AGENT or RCTI without an agreement_ref is refused. The error names the section so a missing mandate is not a silent skip.

Utilities (Eskom, municipalities) start in transition mode. You will see the amount, but Eskom (or the municipality) still sends the bill. The figure on the site view is a reconstruction — labelled billed directly by {utility} — shown for reconciliation — not a tax invoice, not numbered, and not something you claim as input VAT. The day they consent, the next month becomes a platform document. Past months stay reconstructions so the platform does not issue a second tax invoice for a supply the utility already billed outside it.

The same utility can wear two hats: a network operator who charges you use-of-system, and a market supplier who gets paid by the Market Operator. One legal block, two number series. Their market hat is supply-only — they may register generating Trading Units, never demand. A demand-side line against that party is an anomaly, not a billable month (B10).

The grain election, and why there is only one tax invoice per supply

A tax invoice needs one supplier. Both the per-entity document and the single-issuer organisation consolidation satisfy that. VAT Act §20(1) allows only one tax invoice per supply, so the same month cannot be both. Each issuer elects, per recipient organisation, which layer is the tax document:

The layer that is not the tax invoice is issued as a pro-forma annexure carrying its parent’s number. Changing an election writes a new row and closes the previous window on the change date — it is never retroactive. That is the interim B6 position.

Careful. Two tax invoices for one supply is a SARS question, not a screen defect. The run will refuse to issue the second. If you need the other grain, change the election before the month is issued.

5. Numbering — gapless, at issue, copy means copy

A tax invoice is not a tax invoice without a serial number. This chapter is the number half. The artifact half (the stored PDF and its hash) lands with MB2; this page is already the place that chapter will grow into.

Where this is taught. Who may take a number — §4. Why a discarded draft must not burn one — VAT Act §20, and the SARS question a gap becomes.

Why numbers are gapless

Each issuing capacity keeps one series per document kind (tax invoice, credit note, self-billing invoice, pro-forma). The next number is allocated by a single database UPDATE … RETURNING. Two billing runs firing on the 1st cannot take the same ordinal. A rolled-back transaction does not consume one.

A gap in a tax-invoice series is a question you will be asked. The platform does not leave that question for a clerk to reconstruct from logs.

When a number is allocated

At issue. Never at draft.

A document that is prepared, reviewed, and discarded has no number. Only the action that makes the document exist — the issue — takes the next ordinal and writes an allocation row (series, ordinal, taken_at, optional document_id). MZ2’s continuity audit reads those rows, not the documents.

Annual-scope series (the default) restart at 1 on 1 January and put the year in the formatted number: MO-TAX-2026-000001. A non-annual series keeps counting.

What a reprint marked copy means

VAT Act §20(1): one tax invoice per supply; reprints marked “copy”. Asking the series for a copy of an existing number returns that number plus the word COPY and does not increment the ordinal. A copy is not a new invoice. It is the same invoice, again.

Versions are not new numbers

A month that has to be re-issued (re-settlement, a dispute outcome, a timetabled rerun) is a new version of the same supply, plus a §21 credit or debit note that references the original number. The original artifact stays. The note takes the next ordinal on the note series. You never quietly edit an issued number.

The Virtual Wheeling refund is one more numbered document under these rules: an Eskom credit note at account grain, immutable after issue, corrected by a version or a note — never edited in place. The V15 volume is where that document is taught; this chapter is why it has a number.

Careful. If you are looking at two PDFs with the same number, one of them must say COPY. If they say different amounts and neither says COPY, that is a defect — stop and raise it. Do not pick one.

The stored artifact

An issued document is bytes plus a hash, not a re-render. The platform writes the PDF once (WB.Billing.Artifact.put/3), addresses it by sha256, and refuses updates and deletes at the database. Storing the same bytes for the same subject returns the same row. Different bytes are a new version — never an overwrite.

HTML is the source of truth. The PDF is derived from it by a deterministic writer so two renders of the same document are byte-identical. A reprint marked COPY is the same number, with a watermark, and does not take a new ordinal.

Where this is taught. Who may take a number — §4.

What the face says

A Market Operator document carries the market’s face: SAWEM at the top, You pay the market, and the Market Code’s payment clocks. Every other document is between two parties on the platform, so it carries the issuer’s own name. A generator’s tax invoice to its buyer says You pay IPP 1, lists each line’s time-of-use period, kWh and c/kWh, and asks for payment by the due date as the power purchase agreement sets out. Eskom and municipal documents point to your agreement with them instead.

The face is fixed when a document is issued, and a stored PDF is always shown exactly as issued. Only a document whose stored file is a placeholder is drawn from its record when you open it, as some demo documents are.

6. The monthly run — what happens on the 1st

You do not press a button to start the month. The platform does, in UTC, and this chapter is the walk you replay when someone asks why isn’t my invoice here yet.

Times below are SAST. The platform’s clock is UTC: 03:00 UTC is 05:00 SAST. That choice is deliberate — the crontab sets no timezone.

Where this is taught. Settlement statuses the run advances — V6 §11. Who may issue after the evidence is solid — §4.

The chain, numbered

1. 04:00 SAST — refresh the continuous aggregates for the closed month (settlement_intervals_*, wheeling_consumption_*). If this fails, the rest of the chain does not start. A stale aggregate would print a wrong invoice.
2. 05:00 SAST — settle every monthly PPA whose window just closed (the existing settlement runner).
3. Preflight — per organization, five named checks. Coverage and missing rate tables warn and proceed (the bill is stamped PROVISIONAL). A missing VAT rate or an unresolvable payee refuses — an invoice cannot be issued without them.
4. 06:30 SAST — issue a settlement statement for every party on every non-reversed period. A FINAL or DISPUTED period is skipped with a run row, not an error. One organization’s failure does not take the month from everyone else.
5. Share-for-review — those periods move DRAFT → PRELIMINARY automatically. A statement is evidence, not a demand.
6. Five business days later (or the moment you click Finalise) — PRELIMINARY → FINAL, unless a dispute is open. That window is B7: long enough for a counterparty to read a statement. A utility clerk may approve earlier from /operator/run — same gate (FinalisePolicy → IssuerRunner for that issuer only). The window still fires if nobody clicks. Generator-site and trader-supply issuers do not have that button; their approval is the grain election.

What a miss looks like

Every stage writes a run row. A miss is a row you can find (callable, billing_period, outcome, miss_reason), not a silence. If aggregates failed, statement cadence records refresh_aggregates is not ok — hard stop and stops.

Provisional versus final

A provisional bill is still a bill. Metering was incomplete, or a rate table was missing, and the face of the document says so. You may rely on it to see the shape of the month. You may not treat it as the tax invoice you will pay against until the period is FINAL and the issued document exists.

Careful. Preflight naming a missing rate on the document is the alternative to a silent zero. If you see rate not configured, stop — do not invent a number.

The advertised clock

The “next settlement run” on the contract is the crontab, not a second clock. If those two ever disagree, the test that names both fails. That is the point.

7. Per-entity documents — one issuer, one site, one month

You settled June. The ledger already knows who owes whom. This chapter is the first document that is allowed to ask someone to pay: one issuer, one entity, one month.

Where this is taught. Who may issue — §4. How the two layers share tax standing — §8. The register you search afterwards — §9. The numbers themselves — V8 §8.

The problem

A statement that says “Karoo is owed R 292,410 across two offtakers” is evidence. It is not a tax invoice. Finance cannot file it, VAT cannot cite it, and Acme cannot pay “the IPP statement”. Acme pays the document addressed to Acme, numbered, dated, and hashed.

What the atomic document is

A per-entity document is the smallest money document the platform issues. The issuer is the payee on the ledger pair. The entity is the site, pool, trading unit or balancing group the charges belong to. The month is the billing period. Direction is not a setting you pick — the net decides:

• the recipient’s net is negative (they owe) → tax invoice
• the recipient’s net is positive (they are owed) → credit note

A pair that nets to exactly zero produces no document. There is nothing to collect and nothing to remit.

The six charge groups

Every line lands in exactly one group. A new charge category is not allowed to fall into “other”.

Where this is taught. A :rec or :carbon line is a certificate, not energy — quantity_kwh is empty. Who may put that line on a document, and what it looks like, lives in V19 §11. | 5. Residual | Grid energy the PPA did not cover | priced at the utility residual rate — not a ledger category | | 6. Corrections | A later month putting a dispute or rerun right | dispute correction |

Why a charge and a compensation are two documents

Eskom charges Acme for wheeling and credits Acme for WER in the same month. Those are opposite-direction supplies. They do not net onto one invoice. You receive an invoice for the use-of-system and a credit note for the wheeling refund. The ordered pair {payer, payee} is the bucket, not the unordered pair {Acme, Eskom}.

How to read the provenance block

Every line must say where it came from — a ledger source_ref, a clause, a source_term the settlement engine already wrote and never showed you. If a line cannot name its source it cannot be defended in a dispute, and the run will not issue it.

Careful. Only a FINAL period may back a tax document. A PRELIMINARY month is visible as a pro forma so you can see the shape before it is billable. Re-running after finalisation adds the tax documents; it does not duplicate the pro formas.

8. Consolidated invoices — one issuer, one organisation, one month

You have one document per site. Your finance team pays you, not each of your sites. The issuer therefore also produces one document addressed to the recipient organisation, for the same month, that is the sum of those per-entity documents.

Where this is taught. The atomic document and its six groups — §7. The grain election — §4. Payment terms you negotiated — V7 §4.5.8.

The problem

Two generator sites sold to the same offtaker organisation. Two tax invoices is legally fine and operationally painful if that organisation pays once. Two organisations with different payment terms on the same consolidation is worse if you silently pick the later date.

What the consolidation is

The consolidated organisation invoice is still a single-supplier document. It may carry tax-invoice standing. It may not span issuers — that is a statement of account, and it lives on the receiver side (§11, §12).

Exactly one of the two layers is the tax invoice. The other is a pro forma annexure. The grain election decides which:

• Per-entity (the default for generator sites and selling traders) — each site document is the tax invoice; the organisation roll-up is the annexure.
• Organisation-consolidated (the default for Eskom, a municipality, and the Market Operator) — the reverse.

The coverage rule is the same either way: one supply, one tax document. Trying to tax both layers is refused.

What an annexure is

An annexure is a document you can open and print that does not take a tax-invoice number as the legal document for that supply. The trader book — procured versus sold, the mixed-sink P&L — rides as an annexure on the trader’s documents. It was always computed. This is the first time a reader can see it on a bill.

Earliest due date, never the average

Invoice Cycle (MONTHLY or END_OF_MONTH) and Payment Due (days) live on the PPA you already negotiated. They finally reach the document.

• MONTHLY — due date is the issue date plus the agreed days.
• END_OF_MONTH — due date is the last day of the issue month plus those days.

When one consolidation spans PPAs with different terms, the document due date is the earliest. The document lists the per-entity dates it contains. It does not average them and it does not take the latest.

A missing term uses the named fallback of 30 days and the document says standard terms. Weekend due dates stay on the weekend (B12).

Note. A preliminary month issues pro forma at both layers so you can see the consolidation before it is billable. After the period finalises, the elected tax layer is issued; the pro formas stay, superseded in role, not deleted.

9. The issued register — what you put out, still there

You issued a tax invoice on the 1st. A week later a clerk asks for number MO-TAX-2026-000014. If the answer is a search of email or a re-render of a screen, the number is not a register — it is a rumour.

Where this is taught. What a tax invoice is, and why a roll-up is not one — §2. How the number is allocated — §5. How a month becomes these rows — §7 and §8. The operator portal that sits on this register is /operator.

How you get here

/operator is not a login of its own. Open Billing from the Eskom door or the Municipality door on the landing page. That POST establishes the issuer session and lands on this register. The issuer chip is the legal name of that utility — Eskom Holdings, or the municipality you signed into — not a generic “Operator”.

If Billing refuses, no issuer row exists for that door. That is a configuration miss (B13: doors are the interim identity story), not a wrong password. There is no query-string escape hatch onto another tenant.

The problem

An issuer that cannot find what it issued cannot answer a SARS query, cannot prove a gapless series, and cannot tell a recipient “this is the document we sent you” when the recipient says they never got it.

What the register is

The issued register is every document this issuing capacity has created, including drafts you later voided and versions you superseded. It is not a folder of PDFs. It is the same row the recipient holds as a received record. Search it three ways, because those are the three questions you are asked:

1. By month — “what did we issue in June?”
2. By entity — “what did we issue for this site / pool / trading unit?”
3. By organization — “what did we issue to this customer?”

Kind, direction and status compose with those three. The sort is stable (month descending, then the row id) so a page of results does not jump when two documents share a period.

Nothing is ever deleted

A voided invoice stays on the register with status VOID. A superseded invoice stays with status REISSUED. The artifact is still there; the number is still in the series. Deleting either would open a gap that a numbering audit cannot close.

You discard a draft before it is issued. That does not take a number. After issue, the only way off the face of a document is a credit note or a void — both of which leave the row.

Careful. Delivery is part of issue. The same write sets issued_at and received_at. There is no “we sent it” state the recipient cannot see. Acknowledgement is recorded when they look; it is information, never a precondition for payment.

Issuing and approval

The issuer run (0 5 1 * *, after statements) walks every active generator-site and trader-supply issuer, builds the per-entity documents, then the organisation consolidation, and issues both in one write. You do not click “raise invoice” for a settled month.

A period that is still preliminary yields only pro forma rows — visible on the register, not billable. After finalisation the same run adds the tax documents. Re-running an unchanged month does nothing: no new number, no new ordinal. A changed month after the recipient has seen the document emits a credit note; the prior artifact stays.

Approval, for generator-site and trader-supply issuers, is the grain election and the finalise gate — not a second clerk. Utility issuers approve on the operator portal (/operator): a clerk searches the same register by month, entity, and organization (those three facets are mandatory and come first). Kind, direction, status and an amount range compose with them. The totals strip (count, Σ excl, Σ VAT, Σ incl) is the filtered set, to the cent — the same figures the CSV exports.

Approval on Month run moves a pro forma month to issued tax documents. Re-issue writes a version plus a note, never a mutation of the artifact. Month-pack ZIP downloads the month’s PDFs and the register CSV; the button names why it is disabled when the month has no documents.

The received-records tab on the same portal is the Market Operator remittance for the utility’s supply-only BRP hat — both roles in one place.

10. Your received records — what arrived, without you asking

You did not raise these invoices. Someone else did — a generator, a trader, Eskom, a municipality, the Market Operator — and the same row they keep on their issued register is now sitting in yours.

Where this is taught. What a tax invoice is — §2. How a month becomes documents — §7. The site view that groups who you pay — §11. The Billing Hub that holds this tab — §12.

The problem

Finance used to wait for a PDF in email, re-key the number, and hope the amount matched the settlement statement. That is three places the same figure can drift. Received records are the one place the document actually lives.

What arrives

Every document addressed to your organization lands here when the issuer run finishes on the 1st. You do not upload it. You do not approve it to make it exist. It is already the legal document.

You search it three ways, because those are the three questions you are asked:

1. By month — “what did we receive in June?”
2. By entity — “what landed for this site?”
3. By issuer — “what did Eskom send us?”

Open Billing → Documents, then choose Direction: Received. Status and text search compose with these filters. Unread rows are labelled until you mark them as seen.

What acknowledging does

Mark as read in the document drawer records a timestamp on the row. It is a clerk’s tick, not a precondition. Payment, disputes, and re-issues do not wait for it. The unread label changes; the amounts do not.

Finding a document three ways

The number opens a detail drawer. Open original PDF at the bottom right of the drawer displays the stored artifact in the document viewer. Do not re-type the amounts.

How a document reaches you

The portal always has it — issuance writes received_at in the same transaction. Email is on request, and only to an address your organization has confirmed. Confirm the address once; a stale inbox is a disclosure incident, not a bounce. The API is the third path: §18.

11. The site view — who you pay, on one page

A site can take energy from a generator, network charges from Eskom, a WER credit from the same utility, and residual kWh that never wheeled. Those are different issuers. The site view groups them by who needs to be paid, then by the six charge groups inside each issuer.

Where this is taught. The six groups on an atomic document — §7. Residual as information versus a utility bill — §13. The hub that opens this page — §12.

The problem

A settlement statement is one agreement, one run. Your site is not. You need one page that answers “who do I pay for this site this month?” without merging those payments into a single tax invoice.

Site scope in the workspace

Choose Entity on Billing to scope the overview and documents to one site. On Overview, choose By site / entity and select a charge bar to open its documents. The former Sites link opens this grouping. A document drawer exposes its charge lines and original PDF. The six-group assembly below remains the underlying conservation model; it is no longer a separate top-level tab.

How to read the site assembly

1. Issuer groups — one block per issuer. That is who you pay. Karoo’s energy invoice is not mixed with Eskom’s network invoice.
2. Six charge groups inside each issuer — energy, network, credits, adjustments, residual, corrections. Each group closes with excl VAT, VAT, incl VAT, and the backing document number.
3. Savings — what you avoided versus the grid. On Example A the block is R 87,210.00 (physical WER + residual versus Megaflex + network avoided + ancillary avoided). It is a derived figure, not a charge.
4. Residual — unmet kWh priced at the applicable utility tariff, labelled as information. If the utility bills that residual through the platform, the tax document is theirs (§13). A site with no residual shows no section.
5. Conservation footer — the site view’s total reconciles to the site’s billed lines for the month. The footer states that as a checked fact. This page is not a tax invoice.

A utility still in transition has no platform document number. That group is labelled billed directly by {utility} — shown for reconciliation.

Privacy

When one off-taker buys from two sellers, the view shows both issuer groups and the consolidated WER. You see the other seller’s volumes. You do not see the other seller’s prices.

What this page is not

It does not replace the documents listed in each issuer group. Those are what move cash. The site view is the conservation check that they still add up.

12. The billing hub — understand the month, then act

You need to know what remains unpaid, which bill needs checking, and which document explains a figure. Open Money → Billing (/org/billing) in your organization seat. Overview is your starting point. Manual at the top right opens this volume at the chapter for the view you are on.

Billing runs a month behind: a month’s documents are issued after the month closes. So Billing opens on the latest month that has a document in scope, not on the calendar month. A link that names a month opens that month.

Where this is taught. Received documents — §10. Receipts and payments — §16. Utility checks — §22. Portfolio performance belongs in the Room.

12.1 Three views, one month

Check bills is a tab only when your organization has an off-taker site, because utility bills belong to the sites that buy. An old link to it still opens, says there is no bill to check, and links to Off-taker sites.

Billing month and Entity stay selected as you change views. Source selects Wheeling, Market or both for document amounts. If your documents use several currencies, select Currency; totals never combine denominations. Utility checks use the selected month and entity’s own tariff.

Documents keeps Status, Counterparty, search and Show pro formas in view. More filters holds Billing periods, Balance and Due date, and Direction when your organization both receives and issues documents. It opens by itself when one of them is set. Sites are an entity scope and an Overview grouping. Market is a source filter with its credit-cover explanation. Old links to the former seven tabs still open their corresponding view and filters. A Payments link opens Documents filtered to outstanding balances.

12.2 Read Overview from top to bottom

Every amount on Billing includes value-added tax (VAT), so each figure matches the documents behind it.

The first sentence names overdue money in every open month, not only the selected one, and the months it comes from, for example R 15,108.77 is overdue to collect, from July 2026. When nothing is overdue, it describes the selected month. To pay and To collect show the selected month’s outstanding amounts after recorded payments, and how much of each is overdue. The balance date is shown separately from the billing month. These two sides do not net.

The utility review tile appears with Check bills. It counts uploaded bills whose lines are mapped and whose findings have been reviewed. It does not claim that every expected bill has arrived.

The aging bars share a scale. Select a bar to inspect that side of your open balances. Needs your attention lists the overdue documents of every open month, with how many days the oldest is overdue, and any uploaded bill that needs review. Its overdue link opens Documents at Overdue across All open months. A dispute remains alongside aging; it does not stop the clock.

Where this month’s charges sit groups the documents you received by issuer or by site/entity. An organization that only issues documents, such as an IPP selling under power purchase agreements, sees Where this month’s revenue comes from instead: what it issued, by customer or by site. An organization that does both can choose either. Select a group to open its documents.

Billed over time compares six months of received and issued document totals on a chart whose vertical axis is labelled in Rand. The selected month is shaded. Select a bar, or a month in the list below the chart, to open that month. From the keyboard, Tab to the chart, step through the months with the arrow keys and press Enter to open one. Each month in the list names its amounts, such as Issued R 29,636.81. Credits reduce totals. Draft, void, replaced and pro-forma documents are excluded. Drafts are identified, and an empty month says No documents. The overview is not a tax invoice.

A month without documents says so and hides the aging bars. A button opens the latest month that has documents, such as Open August 2026, the latest with documents.

Follow along. Seat: IPP 1 (Organization door). Path: Money → Billing. You should see: August 2026 open, with R 15,108.77 is overdue to collect, from July 2026 as the first sentence and no Check bills tab.

12.3 Follow an amount to its evidence

flowchart LR
  A[Read the month overview] --> B[Select an amount or task]
  B --> C[Inspect its documents or bill]
  C --> D[Review evidence or record a receipt or payment]

1. Select an overdue task, charge driver or aging bar.
2. Inspect the filtered documents, or open the selected utility bill. The Showing line names every filter in force, and Clear filters removes them.
3. Select a document number to open its drawer. You see the original amount, VAT, the balance with its due date (Due 1 Oct 2026 · in 3 days), the charge lines with their kWh × c/kWh where the document carries them, related documents, and the receipts and payments recorded against it. A pro forma and the tax invoice issued from the same lines link to each other.
4. Open original PDF at the bottom right of the drawer displays the document. View settlement evidence opens the settlement statement the document was billed from.
5. Record a receipt or payment, or review a utility finding, in its context.

The open document is part of the page’s address. Back closes it, and a link that names the document opens it again. Escape closes the PDF first, then the drawer, and returns you to the document’s row in the register.

Mark as read acknowledges receipt; it does not approve or pay a document. Utility uploads remain reconciliation evidence, not platform tax invoices.

12.4 Exports and empty states

Export this view on Documents preserves the visible register’s filters, including All open months. Download month pack covers the whole organization for the selected month, regardless of entity or source filter. The line under the button says what it holds, for example 4 issued · PDFs and registers. A month without documents turns the button off and says so. See §18.

An empty register names the filter result and offers Clear filters. Missing tariff evidence and unmapped utility lines are explained. Complete bill comparison totals are withheld until the required evidence is available.

13. Eskom and municipal billing — what they charge, what they credit

You already have a PPA. The utility still has a bill. This chapter is that bill: network charges, the credits that make wheeling work, the electricity your PPA did not cover, and who pays the wheeling charge when the deal says shared.

Where this is taught. How a month becomes documents — §7. The operator register a clerk searches — §9. How the factors are derived — V8 §4. Who gets access to the operator portal — V21.

The problem

A wheeling deal does not replace your utility account. Eskom (or the municipality) still charges for the wires, still refunds the generation that reached your site, and still bills the residual you drew from the grid. If those amounts appear only as settlement lines, you cannot pay them, dispute them, or show them to a finance clerk.

What the utility charges

A dimensioned capacity charge stays in R/kVA against notified capacity. It is not rewritten as a c/kWh equivalent.

What the utility credits

WER is the refund for wheeling generation to your own site. It is computed per interval because min() is non-linear — never from TOU totals. Where the two figures differ, the document shows both.

Eskom refunds a buyer once over the aggregated profile. Summing per-PPA WER double-counts. The document uses the aggregated figure and names the difference.

Explicit versus embedded municipalities

An explicit municipality issues a use-of-system charge. An embedded municipality issues the WEPS-less-losses credit instead — the charge is already inside the municipal retail tariff, so a second invoice would bill the same wires twice.

The residual

The residual is the electricity you drew that your PPA did not cover. It is priced at the applicable retail tariff (Eskom GridTariff, or the municipal retail tariff — never the other way around). Default mode is informational: you still receive the utility’s own bill; the line appears in the site view so you can reconcile. Checking that utility bill against your own intervals and tariff is §22. full_bill puts the line on a platform-issued document. Until B5 is answered, informational is the default everywhere.

OffTakerBill is the residual worksheet (B13). It is not a tax invoice and does not take a number from an invoice series.

Who pays the wheeling charge

The PPA decides. Four allocations, all of which now land on documents:

A shared split shows on both parties’ documents and the parts sum to the whole. A deal that pinned its own factors (binding_mode: FIXED) is billed those factors, not the published tables.

Transition mode

While a utility has not onboarded you will see the amount here and still receive the bill from them. Leaving transition is a date, not a toggle — documents from that month forward only.

Careful. An Eskom issuer must not emit PPA energy. That is the seller’s supply. Residual energy is the only energy line a utility may issue, and only when full_bill is on.

Reading your own documents

Open a row from the issued register. The document page is the artifact the counterparty holds — it does not re-render. Lines sit in the six charge groups. A dimensioned UoS line keeps R/kVA or R/day. A WER credit in group 3 keeps its per-TOU detail. A WEPS month is a credit-direction document (a note), not an anomaly — that class is reserved for a market supply-only invoice-direction flag.

Provenance cites period ids and hashes. It never links into the counterparty’s /org screens.

Walking a month as a clerk

1. Preflight on Month run — each named warning or refusal with its code.
2. Pro forma rows appear while the period is preliminary.
3. Approve month finalises and issues. The page re-reads the database; it does not paint “approved” from the socket. A second click is a no-op.
4. Re-issue needs a non-blank note. You get version N+1 and a §21 note; the superseded row stays and links forward.

If nobody clicks, the B7 window still finalises after five business days unless a dispute is open. The operator seat is who may approve early, not a second clock.

Receiving the Market Operator’s remittance

Received remittances are the utility’s supply-only BRP hat. Amounts, payment state, and the same artifact viewer as the issued side. Acknowledge writes acknowledged_at — visible here and on the MO’s remittances split. No supply-only registration: This operator has no supply-only market registration; nothing is remitted to it.

An invoice-direction flag on that hat (supply_only_invoice_direction) renders the anomaly strip with the run’s reason. A WEPS credit you issued never triggers it.

Settings

Grain election is per recipient organization, effective-dated, never retroactive. A change names the first month it affects. Transition mode is read-only on this page (B14 — flipping it stays with MO/ops). Delivery addresses follow the confirmed-address rule: only a confirmed address receives emailed tax documents.

14. Market Operator billing — two directions, two clocks

The Market Operator does not send you a “month invoice” that mixes everything you traded. It sends one document per party per Billing Period, and the sign of your net decides which document that is.

Where this is taught. The §15 arithmetic lives in the SAWEM engine. This chapter is the tax document that engine now persists. Per Trading Unit and Balancing Group documents are annexures under the party tax document. The org market roll-up and Master Statement live on §12. The operator’s issued-documents room is V11 §19. The Accounts board that counts into that register is V11 §18.4.

The problem

You already received an Indicative Settlement Statement the day after delivery. That statement exists so you can check the figures before they become money. If the Market Operator billed you from it, the seven-working-day Data Verification Period would have nothing to correct against.

So an indicative statement is never billable. The Code says so (§2.1(102)). The platform refuses to raise an invoice from one, and names the refusal :indicative_statement_is_not_billable.

Two documents, two clocks

You do not invoice the Market Operator. The extra day on the market’s side is the cash-flow buffer, not a courtesy.

A month that nets to exactly zero produces no document. A zero invoice is a row somebody has to reconcile for no reason.

What is on the document

The tax-invoice number is gapless and comes from the Market Operator’s series. The bank reference is a different string — it is what both bank statements show so an EFT matches a bill without a call. Do not treat them as the same field.

VAT on the document is the rate in force for the Billing Period (the same VatRate row the rest of this volume uses). The statement items themselves exclude VAT (§15.1(2)); the document adds it.

A miss is a row

If the cadence finds no parties, or no statements, or no published Settlement Calendar for the year, the run is recorded as a miss with a named reason. It is not a green count: 0. The calendar is the authority for the clocks — the engine does not guess “five working days from today”.

The wording on the remittance

The Code’s own name is Self-Billing Invoice (§2.1(178)). That is the title on the document. “Credit Note (Remittance)” is a description of what it does, not a substitute title. That is the interim answer to B8 until a commercial decision changes the face wording.

Trading Unit and Balancing Group annexures

A Trading Unit document itemises every charge and every credit for that unit — never a netted summary. It is a pro forma annexure. The netting that decides invoice versus remittance happens at party level. Positive still means the Market Operator pays the participant; the stored sign is not flipped.

A Balancing Group document carries the BPM_GROUP_* lines. If your units are in a group, the group is charged instead of the units, not as well as. §13.10 replaces §13.4, §13.5 and §13.9 for those periods. A mid-month membership change is shown as two states, not resolved silently to one.

Per-unit payment destinations

Different funders can back different units. The destination on the Self-Billing Invoice is TradingUnit.payment_destination_account — the participant’s own bank account. That is not the SettlementAccount held in the Market Operator’s name. The two types cannot be substituted.

Invoice splitting (N tax invoices whose union equals the party’s net) is a per-party election and defaults off. B6: unit-level tax invoices are not required at launch.

The party document is the tax document

The Code already decides the direction: Statement.direction/1 reads the net and returns invoice, self-billing invoice, or none. Billing does not recompute that. It issues one Tax Invoice or one Self-Billing Invoice per party per Billing Period, from the published Settlement Calendar — Invoice due 12:00 +3BD, Self-Billing due 17:00 +4BD. A run without a calendar is refused. A zero-net party gets nothing.

The face keeps the Code’s name. Under it sits a remittance subtitle so a finance reader who has never opened the Market Code knows what arrived: Self-Billing Invoice — remittance: the market pays you. That is B8 as shipped.

Trading Unit and Balancing Group documents stay PRO_FORMA. They attach as annexures. An attempt to make both layers taxable is refused and names the covering party number.

Debit notes and the Debit Note Excess

When an unsecured bad-debt cascade claws money back from creditors, each affected party receives a Debit Note. The arithmetic can ask for more than the market still owes that party this month. That difference is the Debit Note Excess: the market can claw back more than it owes you this month, and the difference is due in cash within two business days. The note states that on its face. Do not discover it from a bank balance.

Supply-only BRPs

Eskom and municipal Balancing Responsible Parties supply to the market. They do not buy energy from it. A demand-side energy line on that party is refused at the document boundary, even if someone bypassed preflight to re-issue by hand.

A normal month is a remittance. An invoice-direction month can only come from charges (MO fees, imbalance). That month is flagged for review and not issued — B10. The document, when a remittance does issue, states the supply-only role so a utility finance team reading it knows why there is no purchase side.

A utility that wears both hats keeps two series: market documents come from the Market Operator’s series; network documents come from its own.

The Market Operator billing room

/mo/billing is the issued-documents room — sidebar Billing, in the Settlement group, next to Accounts. The operator walkthrough — tabs, facets, ids, the document page — is V11 §19. Issuing still happens on Cadence (Run the month); Accounts holds the cash. This volume keeps the tax-document rules.

The register is split by kind: Invoices, Remittances (SB), Debit Notes, and Notes each show the same documents card as the operator register, with totals for that kind only. Kind chips say Invoice, Remittance (SBI), Debit note, and Note — the Code term and the plain word both appear (B8), each as a coloured badge. Status is a badge too. Organization is the legal name, not the uuid. Period is written 1 June 2026. Excl / VAT / Incl (and the totals strip) are rands. Search is by BRP, trading unit, organisation name, or document number. The eye (#mo-doc-view-{id}) opens the stored PDF on the same page. The totals strip and GET /mo/billing.csv still agree with the rows to the cent.

Overview rolls up invoiced, remitted and debit-noted to date. Remittances (SB) marks utility rows acknowledged or unacknowledged against the operator Received page. Correction keeps note → original. Run status is read-only cadence.

The billing-board counters on Accounts (#run-invoices, #run-self-billing) open Invoices and Remittances (SB) for that month. A count that disagrees with its own drill-down is worse than no count.

Credit cover on the roll-up

§15.10(8)(a) defines Actual Exposure as invoices issued but unpaid plus amounts in issued statements not yet invoiced. The Market tab shows that figure and says so. Persisted documents make the number real; an in-memory engine run does not.

15. Virtual PPA billing — three layers, one hedge

A virtual PPA does not wheel electrons from the seller to you. Eskom still bills you in full and still pays the generator. The contract is a hedge: the two of you settle the difference.

Where this is taught. How virtual settlement is computed — V8 §14. This chapter is the document that hedge becomes.

The problem

You already have an Eskom bill. If the platform also invoiced you for the same kilowatt-hours, you would pay twice. If it issued you a WER credit that Eskom also issued, you would be paid twice. The virtual document has to show three layers and bill only the one that is ours.

The three layers

1. Eskom bills you in full for everything you drew from the grid (layer 1 on the generator side: Eskom pays the IPP its generation tariff).
2. Eskom pays the generator / applies WER — the wheeled-energy refund on the matched volume. This is information on our statement. We do not re-issue it. Eskom already did (or will).
3. The CfD is the difference you and the seller settle between yourselves. It can flow either way in a given month: the loser of the month pays the winner.

Layer 2 is labelled as information and is not included in the zero-sum totals of the CfD ledger. The saving versus the unhedged grid bill equals the off-taker’s ledger net — Example A’s identity (R 69 100.00).

Why the CfD can reverse

Strike versus credit is a signed difference. A month where the credit exceeds the strike is a month the seller pays you. Opposite-direction supplies stay two documents (the ordered-pair rule from §7). A nomination shortfall is a separate document, not a netted line on the CfD.

WER on a trader-intermediated deal

Eskom computes WER from the registered IPP meter data it allocates, not from the trader’s nomination. The two can diverge. The document discloses the divergence. It does not absorb it into the CfD.

The vendor fee

The VWP vendor admin fee is issued by the platform issuer in its own name (B4 interim). There is no sixth issuer kind.

Intervals

Virtual periods do not write settlement_intervals. WER on a virtual statement comes from the persisted line items, not from an empty interval read.

Note. VAT on CfD flows is an open tax question (B1). The platform currently treats them as standard-rated. A change of opinion is a data change, not a rewrite — the treatment is named VatTreatment.interim_standard_pending_b1/0 and pinned by a test that fails when it moves.

16. Payments and aging — the invoice does not shrink

You need to distinguish unpaid invoices from partial payments and money not yet assigned to a document. Open Money → Billing → Documents.

Money moves two ways. A receipt is money a customer paid you against a document you issued. A payment is money you paid against a document you received. Both are records of a transfer that has already happened.

Where this is taught. Fixed issued documents — §2. The workspace — §12. Settlement remains accrued: V8 §12.

16.1 Find what remains open

The document register holds both the paperwork and the cash. Status narrows it to Outstanding, Overdue, Paid or Informational, plus Unread when you receive documents and Disputed. Counterparty names the other side, and the search finds a number, counterparty or entity. Show pro formas adds pro formas back; they repeat the tax invoice issued from the same lines, so the register leaves them out and counts them, for example 2 pro formas hidden.

More filters holds the rest. Choose All open months under Billing periods to include older debt, or keep Selected month. Balance selects To pay, To collect, or both. Direction appears when you both receive and issue documents. The Showing line under the filters names every filter in force, and Clear filters returns the register to the whole month. Recorded receipts and payments sit under the table.

Each row’s Status says where its balance stands today:

The Due column gives the date and the days that matter, such as Due in 3 days or 28 days overdue.

Click an aging segment in Overview to open the documents behind that balance. The Due date filter retains the selected band; choose All due dates to expand the register again.

Payables and receivables do not net. Aging follows each document’s due date: current, 1–30, 31–60, 61–90 and 90+ days overdue. A missing due date is labelled. Disputed documents still age.

16.2 Record and allocate

flowchart LR
  A[Open an outstanding document] --> B[Choose a new record or one already recorded]
  B --> C[Enter amount, date and bank reference]
  C --> D[Record receipt or payment]

1. Select a document number in Documents.
2. In its drawer, find Record receipt for a document you issued, or Record payment for a document you received.
3. If money from the same counterparty is already recorded and not yet allocated, Use a recorded receipt (or payment) offers it. Otherwise you record a new one.
4. Amount (R) starts at the balance. Enter the Date received (or Date paid) and the Bank reference exactly as the bank statement shows it; the reference starts empty.
5. Select Record receipt (or Record payment). The balance, the status and the history update.

The amount must be positive, fit within the balance and have at most two decimal places. The date cannot be in the future. A recorded receipt you reuse must have enough left to allocate, and supplies its own date and reference. When an entry is wrong, the field that needs correcting is outlined and says why, such as R 20,000.00 is more than the R 15,803.23 still to collect on this document, and the cursor moves there. Nothing is recorded until every field is right.

A partial payment leaves the original invoice gross unchanged and shows the remaining shortfall. Informational, draft, void and replaced documents do not offer an entry.

A document has one balance for both parties. When you record a receipt against an invoice you issued, your customer sees the same invoice as paid, or part paid, in its own Billing.

Careful. You are recording an existing transfer. This is not a bank feed, and submitting the form does not move money.

16.3 Unallocated money and records

Money sometimes arrives before you know which invoice it pays. Record an unallocated receipt (a payment, if you only receive documents) opens a dialog. Choose who the money moved with, then enter a Rand amount, the date and the bank reference. A seller chooses from its customers under Received from; an organization that both buys and sells sees customers (money in) and suppliers (money out) as two groups. Later, open an outstanding document from the same counterparty to allocate from that record. Its money can pay only that counterparty’s documents.

Recorded receipts (or Recorded payments) lists the organization’s records across all dates: who the money moved with, the original amount, the unallocated balance and the allocations. Download payment record exports a record and its own allocations as CSV; it is not a bank confirmation or a tax document.

Manual entry is available for wheeling-side Rand documents. Market Treasury is read-only. Linked treasury payments are reflected in the document’s outstanding balance and cannot be recorded a second time here.

16.4 Reverse a receipt or payment

A record entered by mistake, against the wrong customer or with the wrong amount, is reversed rather than deleted. Reverse receipt (or Reverse payment) sits under the record in the drawer’s history and in the records table. It asks for a reason, which stays on the record.

A payment reversal removes the record from every document it paid, so those documents open again: the balance returns, and a paid document goes back to issued. The record stays in the table marked Reversed, with the date, the reason and the documents it had paid; the drawer lists it under Reversed. Record the transfer again if the money did move. Market Treasury records cannot be reversed here.

17. Corrections and reissues — a note, not a replacement

A month that was wrong does not get a second invoice with the same number. The original stays issued. What arrives is a credit note or a debit note that names the original.

Where this is taught. How a party document is raised — §14. How versions and hashes work — §5.

The problem

Finance already filed June’s Self-Billing Invoice. If the platform quietly replaced that PDF, the file and the bank would disagree, and nobody would know which figure to pay. A correction that overwrites is how two versions of a year-end come to exist.

What a version means

Issuing allocates a gapless number and binds an artifact. After that, the cents, the lines, and the hash do not move. A later figure is a new document with its own number. It references the original; it does not supersede the file you already have.

The original stays ISSUED. You can still pay it. You can still cite it. The note is the delta.

A rerun is not a dispute

A timetabled rerun is the Code’s scheduled second look at the month. The figures can move. Each party whose net changed receives a note for the difference.

A validated dispute is a party winning an argument. §15.5(3) says the rerun applies to all participants. A dispute you win changes everybody’s month, not just yours. Each affected organization sees the note in its received records. That fan-out is expected. A bilateral quiet settlement is what the Code forbids.

What you will see

On /org/billing the note appears in Received with a reference to the original number. Open either document and the other is named. The Master Statement’s register lists both.

Careful. Payment is still due on the original. A dispute does not pause aging. The note adjusts the position; it does not withdraw the claim.

18. Analysis and exports — compare the invoices you hold

You need comparisons that agree with your documents. Open Money → Billing → Overview. The former Analyze link now opens this overview.

Where this is taught. The workspace — §12. Payment records — §16. API access — V13.

18.1 Questions the charts answer

Where this month’s charges sit ranks received totals by issuer or site/entity. For an organization that issues documents, Where this month’s revenue comes from ranks issued totals by customer or site. Selecting a bar opens its documents. Billed over time compares six months of received and issued financial documents on a chart with a labelled Rand axis. Selecting a bar, or a month in the list below the chart, opens that month; the list names each month’s received and issued amounts.

Both comparisons include VAT, like every other figure on Billing, so a month’s issued total agrees with the invoices that make it up. Credits reduce their totals. Pro-formas, drafts, void and replaced documents are excluded. An asterisk identifies drafts, and an empty month says No documents. Entity, source and currency scope apply to both charts.

18.2 Export the register

On Documents, Export this view preserves the filters, including All open months. The CSV includes document number, counterparty, entity, source, currency, original net/VAT/gross cents, outstanding cents, balance side and due date. Pro formas are in it only when Show pro formas is on, as on screen. Integer cents remain exact; the screen formats the same amounts with readable currency and thousands separators.

18.3 Download the month pack

Download month pack produces a ZIP for the whole organization and selected month. It does not shrink to the visible entity or source. The pack contains received document PDFs, a register CSV and a master-summary CSV. Documents your organization issued follow under issued/, with their own issued/register.csv, so a seller’s pack holds its invoices. The line under the button counts what the pack holds; a month without documents turns the button off. The master summary is denominated in Rand and excludes documents in other currencies; those retain their own denomination in the original PDFs. PDFs are stored artifacts, never a re-render.

The master summary is not a tax invoice. Uploaded utility scans remain separate evidence under Check bills; Open original bill retrieves the selected version.

18.4 Other delivery paths

The portal always has issued documents. Email is on request, to an address your organization has confirmed.

GET /api/v1/billing/documents, GET /api/v1/billing/documents/:number (PDF by Accept) and GET /api/v1/billing/registers are own-party. Money travels as integer cents and a decimal string. Cross-party access returns 404. Workspace document, utility-bill and payment-record downloads also enforce organization ownership.

19. A worked month — one close, every issuer kind

This is one August, walked from aggregates to close, so you can see the volume is about a real system.

Data. foundation / full_demo · last walked 2026-08-19.

Provenance

Issuer run on the 1st (0 5 1 * *), org assembly thirty minutes later (30 5 1 * *). Documents freeze from ledger pairs. The receiver freezes from those documents, not from the ledger again.

The cast

What the organization received

Received records list every number. The site view groups who to pay. The market roll-up lists party documents and the §15.10(8)(a) credit-cover basis. Overview’s Master Statement adds wheeling to market. The legend is on the face: this is not a tax invoice.

Conservation

Across issuers, recipients, utilities and vendors the month’s signed documents sum with the payments and notes that follow them. A short payment leaves the invoice intact. A rerun arrives as a note. Close freezes issuance, not cash.

Σ documents + notes + allocations = the month you will file.

20. Terms used in this volume

21. Reference card

Clocks: issuer run 0 5 1 * *; org assembly 30 5 1 * *. Password for seeded users in demo: see the setup runbook, not this card.

22. Bill reconciliation and load-shift

The utility still sends their bill. This chapter is how you check it against the intervals and tariff you already have on the platform — and what you do when a register disagrees.

Where this is taught. The Billing Hub that holds this tab — §12. What the utility charges — §13. Disputes on a wheeling period — V8 §11.

The expected bill

The expected bill is a calculation, not a document. It is never numbered, never issued, and never sits in Received or Issued. For one off-taker site and one month it:

1. Reads consumption from the same physical meter wheeling settlement uses.
2. Splits kWh by the row’s own peak / standard / off-peak registers — not by re-running the calendar classifier.
3. Derives season from the row’s timestamp.
4. Prices each (season, tou) register at this site’s own tariff (OffTakerSite.tariff) — Eskom or municipal, the one join already on the site. It does not use the would-have-paid GridTariff / MunicipalWheelingTariff tables, and it does not reuse the residual OffTakerBill worksheet.

A register with metered kWh and no matching rate is a named error, not a silent zero. Rounding happens once, at the register total, to the cent.

Uploading the actual bill

Open Money → Billing → Check bills. Select a site from the portfolio list, then choose the issuer (Eskom or the municipality), and the PDF or image of the printed bill. Type each printed register label and its Amount (R) to cents. Use the plus control to add a printed line. A corrected re-upload is a new version; the previous file stays.

The platform maps each label to a (season, tou) register with an explicit list — never a fuzzy guess. A label it does not recognise stays on the bill (gross_cents still includes it) with mapped_register empty. Fully mapped means every line has a register. Until then the page says N of M lines mapped and will not offer a bill-level variance total. You can assign a register by hand; that assignment records who and when.

An ingested bill is not a BillingDocument. Transition-mode issuers produce zero platform invoices on purpose. Ingesting the utility’s PDF must not create a second numbered tax document for the same supply.

Variance findings

When the bill is fully mapped, each register is compared at the effective-dated tolerance (seeded at R1 / 100c, the figure the old reconstruction hook used). A finding is agreement, variance, or incomplete_mapping. Selecting a register opens an evidence drawer with the expected amount, uploaded bill lines, original bill link and interval rows behind the expected figure and the ingested line ids behind the billed figure.

A variance you have reviewed can open a wheeling dispute on that site’s settlement period for the month, with ground Bill reconciliation variance. Eskom and municipalities are not organisations on this platform, so the respondent is still the PPA counterparty; the utility’s issuer identity is stored on the evidence snapshot. If the site has no settlement period that month, Raise dispute is disabled and names the reason.

Load-shift card

The collapsed Explore modelled load-shift savings section reads the expected registers: if spare kWh sitting in a dearer TOU band moved into the cheapest band at this site’s tariff, how many cents. Every figure cites the interval evidence that produced it. It is a billing card, not a Money Room detector class.

Portfolio review progress

The site list distinguishes bills awaiting upload, lines needing mapping, missing tariff/meter evidence, and bills awaiting review. The Overview tile counts the latest uploaded bill at each site. A reviewed bill has all lines mapped and all current register findings reviewed. A re-upload starts its own review. An unmapped line or unavailable expected calculation withholds aggregate comparison totals. Open original bill retrieves the stored PDF or image for that version.