Sådan efterprøves evidensen

Celembi kalder sin afregningsdokumentation revisorklar. Det er en påstand, en revisor skal kunne teste uden at stole på os. Denne side siger præcis, hvad evidensen består af, hvad der fastfryses i afregningsøjeblikket, hvordan hashen genberegnes med tre linjer kode, og hvor grænsen går: Celembi er datalaget, ikke revisionen.

Hvad evidensen består af

For hver afregnet leverance findes én rapport (GET /api/v2/deals/{id}/esg-report) med fire blokke:

Hvad der fastfryses ved afregningen

Tallene i afregningen (volumen, pris, beløb) er uforanderlige, når leverancen er afregnet. Men en rapport læser også ting, der ellers ville kunne ændre sig bagefter: CO2-afgiftssatsen, tarifferne, købers erklærede varmealternativ og dets emissionsfaktor, og en eventuel dokumenteret substitutionspris. Alle disse gemmes på leverancen i afregningsøjeblikket som rapportens grundlag, sammen med hashen.

Konsekvensen er den, en revisor har brug for: en rapport hentet om tre år bygger på de samme satser som den dag, der blev afregnet, og giver samme hash. Ændrer nogen et tal i databasen, siger rapporten mismatch. En leverance afregnet, før fastfrysningen blev indført den 6. september 2026, siger not_frozen og beregnes med de aktuelle satser; den er ikke evidens på samme niveau, og rapporten skjuler det ikke.

Genberegn hashen selv

Rapportens revisionsblok indeholder evidence_payload: præcis det objekt, hashen er beregnet over. Opskriften er JSON med sorterede nøgler, uden mellemrum, UTF-8 uden ASCII-escaping, derefter SHA-256. I Python:

import hashlib, json

payload = report["audit"]["evidence_payload"]
digest = hashlib.sha256(
    json.dumps(payload, sort_keys=True, separators=(",", ":"), ensure_ascii=False).encode("utf-8")
).hexdigest()
assert digest == report["audit"]["evidence_hash_sha256"]

Skal en revisor tjekke en udleveret rapport uden at have adgang til tallene igen, svarer GET /api/v2/deals/{id}/evidence/verify?hash=… med fire ting: hashen gemt ved afregningen, hashen genberegnet nu, om den medsendte hash er den gemte, og hvilken offentliggjort sammenfatning den indgår i. Svaret indeholder ingen beløb eller mængder.

Substitutionsprisen: loftet er forsyningens, og prøven står i hver rapport

Efter varmeforsyningsloven må en forsyning kun indregne nødvendige omkostninger, og Forsyningstilsynets praksis sætter loftet for købt varme ved substitutionsprisen: forsyningens egen alternative produktionsomkostning, med forsyningens meromkostninger ved at modtage varmen (stikledning og veksler som annuitet, booster-varmepumpe, pumpning) trukket fra, før sælgers pris bedømmes. Celembi bygger det ind tre steder:

1. Loftet håndhæves. Forsyningen dokumenterer substitutionspris og meromkostning pr. MWh på sin enhed. Derefter afviser platformen ethvert behov med et maksimum over substitutionsprisen minus meromkostningen, og motoren kan aldrig foreslå en pris over behovets maksimum. En handel over loftet kan ikke opstå.
2. Prøven står i hver rapport. Substitutionsprøven i evidensrapporten sammenligner købers samlede pris pr. MWh (varme, tariffer, tabstillæg, temperaturløft) plus meromkostningen med substitutionsprisen, og viser luften i kroner og procent og om prøven er bestået. Er substitutionsprisen forsyningens egen, står der partner_documented; ellers bruges Celembis estimat, og det står der.
3. Prøven fryses. Substitutionspris og meromkostning indgår i det grundlag, der fastfryses ved afregningen, så prøven giver samme resultat, når tilsynet spørger.

Måneden hænger sammen med leverancerne

Månedsrapporten pr. enhed (GET /api/v2/entities/{id}/monthly-evidence-report) summerer de afregnede leverancer i måneden, og den summerer med hver leverances fastfrosne faktor og sats, ikke med dagens. Den bærer listen over de enkelte leverancers hashes i sin egen hash, så kæden fra måned til afregning er en del af evidensen. Den udskriftsklare udgave viser, hvor mange af månedens leverancer der bærer et fastfrosset bevis.

Hvad evidensen er, og ikke er

• Det er et deterministisk, reproducerbart datagrundlag: samme input giver samme tal og samme hash, hver gang, hos os og hos jer.
• Det er sporbart fra bud til måler: ordre, forslag, accept, aflæsning, afregning, med request-id på alle skrivende kald og fem års opbevaring af revisionssporet efter bogføringsloven.
• Det er ikke en revisorerklæring. Celembi er ikke en revisionsvirksomhed; vi leverer laget, revisor bygger sin erklæring på.
• Det er ikke en måling. Målerne er parternes; Celembi læser ikke fra dem. Afviger de to aflæsninger mere end 5 % ud over rørets tab, afregnes der ikke, før det er afklaret, og afklaringen står i rapporten med begrundelse og hvem der traf den.
• Det er forankret uden for vores egen database. Hashen ligger i databasen sammen med tallene, så alene beviser den, at en rapport passer til databasen i dag. Derfor samler et job uden for API'ets skriveadgang hver nat dagens fastfrosne hashes i én fil, beregner en sammenfatning (SHA-256 over de sorterede par af leverance-id og hash), lægger filen som en commit i kodearkivets historik og beder en uafhængig tidsstempeltjeneste (RFC 3161) om at stemple den. Rapporten og verifikationskaldet viser, hvilken sammenfatning jeres hash indgår i, og hvor filen ligger. Arkivet er privat; revisor får læseadgang på forespørgsel. Leverancer afregnet, før dette blev indført, forankres ved næste kørsel. Hent alligevel rapporten ved afregning og gem den: jeres eksemplar er det holdepunkt, der ikke afhænger af nogen.

Siden følger koden: beregningsversionen står i hver rapport, og en ændring af opskriften får en ny version, aldrig en stille genberegning. Senest gennemgået 6. september 2026. Spørgsmål: kontakt@celembi.dk.