Repository navigation
Kraken: applicableRates fallback treats exc-VAT prices as inc-VAT #5417
Description
Activity
This is an automated first-pass triage (a maintainer will review before any action is taken).
Classification: bug · Priority: low — it only affects the GraphQL fallback path and only diverges once VAT stops being zero-rated (1 April 2027), and the fix is already open as PR #5418.
Verified against current main (
v9.3.5-9-g82bee43e):- The fallback does what the report says:
_finalize_graphql_ratesstores the raw GraphQLapplicableRatesvaluestraight intovalue_inc_vatand derivesvalue_exc_vat = value / 1.05(apps/predbat/kraken.py:769-770). The "inc VAT" wording in the query comment is Predbat's own assumption; the schema introspection cited in the report proves neither way. Downstream,value_inc_vatfeeds the tariff model and the published rate sensors;value_exc_vatis written but read by nothing outsidekraken.py. - The cited EDF integration does assert exclusivity:
api_client/agreement_tariffs.pyon itsdevelopbranch says "applicableRates publishes exc-VAT prices only" and applies the same cure proposed here — a vat multiplier derived from the agreement'sstanding_charge / pre_vat_standing_charge, accepted only within 1.0–1.25, applied to import rates only, with the zero-rate window (Oct 2026 – Apr 2027) documented. Checked by reading that file directly; not run against a live account, so the exc-VAT basis remains the reference implementation's interpretation rather than a bill-verified fact. - The
applicableStandingChargesfallback carries the same inc-VAT assumption (apps/predbat/kraken.py:958) — confirming the report's "not covered" note. - The current unit tests bake the assumption in (
test_kraken.pyassertsvalue_exc_vat == round(24.57 / 1.05, 4)for a rawvalueof 24.57), so any fix has to move those assertions with it — which PR fix(kraken): scale exc-VAT applicableRates prices to inc-VAT from the agreement #5418 does.
On impact: the multiplier, if wrong, scales every import period uniformly, so relative arbitration between cheap window choices is unchanged; what drifts is import-vs-export/solar economics and the agreement between Predbat's published rates and the bill. That, plus the deferred appearance date, is behind the low rating.
Trigger paths confirmed in the code: EDF day/night tariffs return HTTP 400 on the REST rates endpoint (see #5166) and products retired from REST return 404/410 (cf. #3763) — both take the fallback every cycle, as described.
No unit test run in this pass: the open question (what the provider's
valuefield actually means) is not something a test of Predbat's own code settles, and the current tests just restate the assumption. PR #5418's verification description covers their side.- The fallback does what the report says:
Describe the bug
When the Kraken (EDF / E.ON) component cannot get import rates from the REST products API it falls back to the GraphQL
applicableRatesquery.kraken.pystores the singlevaluethat query returns asvalue_inc_vat, on the assumption that it includes VAT.The BottlecapDave-derived EDF integration (stevekirtley/HomeAssistant-EDFEnergy,
api_client/agreement_tariffs.py) states the opposite — "applicableRates publishes exc-VAT prices only" — and scales the values up before using them. If that is right, Predbat's import rates on the fallback path are 5% low whenever VAT is 5%.Who is affected
Only tariffs REST cannot serve, which take the fallback every cycle:
Tariffs served by REST read
value_inc_vatdirectly and are not affected. Export is not affected (no VAT).Why nobody will notice yet
GB domestic electricity is zero-rated for VAT from 1 October 2026 to 31 March 2027, so exc-VAT and inc-VAT are the same number today. The error would appear on 1 April 2027.
Evidence and its limits
ApplicableRatehas onlyvalue,validFrom,validTo, with no descriptions — the schema does not say either way.applicableRatesvalue has been compared against a bill here. A user on an affected tariff comparing Predbat's import rate with their bill (after 1 April 2027, or historically) would confirm it.Proposed fix
Take the VAT multiplier from the import agreement's own
standingCharge / preVatStandingCharge(both are on theTariffTypeinterface on EDF and E.ON) and scaleapplicableRatesimport values by it. That is 1.0 during the zero-rate window and 1.05 afterwards with no date logic. Export stays unscaled.Not covered
The GraphQL
applicableStandingChargesfallback is also assumed inc-VAT and is unverified either way.