usaref › Accuracy

Accuracy record

Where widely-published reference values are wrong, and where ours were. Every finding names the governing instrument and tells you how to check it without trusting us.

This exists because provenance is the product. Anyone can publish a number. The claim worth making is that a number was read from the instrument that creates it, on a date, and is re-checked — and that claim is only worth anything if we also publish what we got wrong.

Findings come from reading primary sources, not from comparing one aggregator against another. Where a discrepancy could not be reproduced from a public document, it is not listed. We name instruments, not vendors.

Where commonly-published values are wrong

None recorded yet for the countries usaref serves. This is not a claim that widely-published values for these countries are all correct — only that we have not yet found and confirmed a discrepancy against the governing instrument. Findings are added when a primary source contradicts a common claim, not when a secondary source disagrees with another.

Where we were wrong

6 errors found in data or code we had already shipped. All are fixed; each is listed with what caused it.

Thirteen tax series wore the current code year as their effective date

What was wrong: Several francophone African countries re-enact their entire tax code or annexe fiscale every January. Thirteen of our VAT, corporate-tax and income-tax series (Côte d'Ivoire, Niger, Gabon, Congo, DR Congo, and Mali's 2011 guess) stamped effective_from with the CURRENT re-enactment — an unchanged 18% VAT dated 2026-01-01 — which reads as a rate change that never happened. An outside audit called it 'effective-date inflation' and it was our most systemic metadata fault, the same class of error as the Indonesia correction below: dating the value to the instrument rather than to the rate. The fix ran gazette-level research on every affected series, each finding adversarially re-verified. Eleven series now carry their researched origin — among them Côte d'Ivoire VAT 18% from the annexe fiscale 2003 (per the DGI's own amendment annotations), Côte d'Ivoire corporate 25% from the annexe fiscale 2008 (Journal Officiel facsimile read in full, refuting the widely-believed '2021 cut from 30%' — 30% was never the general rate), Niger VAT 19% from a mid-2000 rectification law, Niger's 30%/ITS pair from the loi de finances 2010 gazette, Gabon corporate 30% from the loi de finances 2013, Congo VAT 18% from the 1997 law that instituted the tax (signed original read on the SGG's own host), and DR Congo's 30% and IRPP barème from the 2018/2019 finance laws that actually set them. Where the origin is corroborated but the gazette text is unobtainable (Gabon VAT's 1995 institution, Mozambique's IRPS schedule, Congo corporate), the value now carries a machine-readable `effective_from_basis: "restatement"` instead — the date is a verified floor, not a change — because silently keeping the misleading stamp and silently guessing an older date are both wrong. One suspect survived scrutiny intact: Congo's 2026 income-tax date is genuine (the finance law really did rewrite the barème).

Instrument: Per-series gazette research, each cited in the series' own source and notes; the flag is documented at /docs and in the OpenAPI schema

Check it yourself: GET /v1/ci/vat — effective_from 2003-07-07 with the 2001 20% window in history. GET /v1/ga/vat — effective_from_basis 'restatement' with the researched origin stated in notes. Diff the /changes feed: restatement rows are marked so a feed consumer cannot mistake a re-enactment for a change.

Nine citations pointed at something other than the instrument

What was wrong: Provenance is what this product sells, and an outside audit found a minority of citations that did not carry their value: a URA sector page cited for Uganda's VAT rate while naming an Order whose text it is not; Mozambique's income-tax schedule pinned to Artigo 54-A — the capital-gains regime added in 2025, whose ladder is deceptively identical in shape to the general Artigo 54 schedule; Côte d'Ivoire's minimum wage cited to a private legal blog, with an agricultural SMAG figure attributed to a decree that (read article-by-article) contains no SMAG at all — that figure is now WITHDRAWN rather than re-homed, because no instrument for it could be identified; Nigeria's minimum wage cited to the State House press release rather than any legal text; Algeria's policy rate cited to the central bank's statistics table rather than the Instruction that sets it; Angola's policy rate cited to an SPA route that serves nothing to a non-browser client; DR Congo's SMIG cited to a news article. Each is now re-pointed at the best verifiable instrument — including Algeria's Instruction n°02-2026 fetched from the Bank's own host, Uganda's operative 2006 Order on ULII, and the DRC Journal Officiel scan that also disproved the audit's own claim that we cited the wrong law number (the JO shows 23/053 is the IS/IRPP reform; 23/052 is procedures). Where no official host serves the text (Nigeria's gazetted Act, Côte d'Ivoire's paywalled JO, DRC's decree), the citation now says exactly what it is and is not, in two labelled parts. One non-error worth recording: BEAC serves its CURRENT rate decision from a reused 2016-dated URL slot that is overwritten at each session — the citation was right all along, and the mechanics are now documented so a changed hash reads as a new decision, not a broken link.

Instrument: Each corrected citation names its instrument in the series' source field; access mechanics (bot-blocks, rotating slots, paywalled gazettes) are disclosed in notes

Check it yourself: GET /v1/dz/policy-rate — the source is the Banque d'Algérie Instruction PDF, not a statistics page. GET /v1/ci/minimum-wage — no SMAG is served, and the notes say why. GET /v1/ug/vat — the source URL is the Order's text.

Euro area — we served the wrong ECB rate for twelve of twenty years

What was wrong: Every euro-area policy-rate series describes itself as the ECB DEPOSIT FACILITY RATE, and its notes say so twice over: 'the ECB steers the stance through the DEPOSIT FACILITY RATE, which is the rate served here'. Twelve of each series' twenty rows carried the MAIN REFINANCING rate instead — 216 rows across 18 countries. The gap is 40 to 50 basis points and it reached callers: a point-in-time query for 1 January 2023 returned 3.0% labelled as the deposit facility rate, when the deposit facility rate was 2.0%; for June 2018 it returned 0.0% when the rate was -0.40%. Anyone pricing off 'the ECB policy rate' for a 2023 date was 100bp out. The MRO is not a defensible substitute here even though it WAS the headline policy rate before the ECB's 2024 framework review, because this service already publishes the MRO separately and correctly as `ecb-main-refinancing-rate` in all twenty of these countries — so the MRO rows inside policy-rate duplicated a series we already served while contradicting policy-rate's own definition. The history has been rebuilt from the ECB Data Portal series FM.D.U2.EUR.4F.KR.DFR.LEV rather than patched, because the two rates do not move on identical dates: the deposit facility rate changed on 18 September 2019 when the main refinancing rate did not, so the old history was missing a change point altogether. Coverage now runs from each country's euro adoption date instead of an arbitrary 2018 floor, and every row is cited to the ECB and marked primary, replacing citations to the BIS compilation.

Instrument: ECB Data Portal series FM.D.U2.EUR.4F.KR.DFR.LEV (key ECB interest rates, deposit facility)

Check it yourself: Ask any euro-area country for its policy rate as at 2023-01-01. It should answer 2.0%, not 3.0%. Ask as at 2019-11-01 and it should answer -0.5%. Ask Croatia as at 2010 and it should REFUSE — Croatia adopted the euro on 2023-01-01 and the ECB rate was not its policy rate before that.

Germany — we refused five and a half years of VAT we could have answered

What was wrong: Asked for the German standard VAT rate as at any date from 1 January 2021 onward, we refused, stating that the most recent value we held 'lapsed on 2020-12-31' and that we held 'no successor covering that date'. We held the successor: 19%, in force since 1 January 2007 and never repealed. Germany cut the standard rate to 16% for six months in 2020 (Zweites Corona-Steuerhilfegesetz, BGBl. I 2020 S. 1512) and 19% resumed automatically on 1 January 2021. Our point-in-time resolver picked the row with the latest START date rather than the row actually IN FORCE, so once the temporary cut expired it kept winning and the open-ended rate it had interrupted was never reconsidered. Two things make this worse than a gap: the refusal asserted something false with specifics attached, and it is the second false refusal we have published (after Indonesia), from a different cause — there the date was wrong, here the date was right and the resolver was wrong. The resolver now selects on the interval a value covers rather than on when it began, and a data-contract checker flags any series whose history overlaps its current value so the shape is caught rather than the symptom.

Instrument: Umsatzsteuergesetz § 12(1); Zweites Corona-Steuerhilfegesetz of 29 June 2020 (BGBl. I 2020 S. 1512)

Check it yourself: Ask for Germany's VAT rate as at any date in 2021 or later. It should answer 19%. Ask as at September 2020 and it should answer 16% and tell you it was superseded on 2021-01-01.

Ninety-nine historical values we serve without a citation

What was wrong: Point-in-time reads (?as_at=) can return a historical value that carries no source of its own. 99 of the 2,633 historical rows we hold are like this, across 32 series in 12 countries — among them GB VAT before 2011, Canadian CPI, Indian and Italian policy rates, and Korean and Philippine wage history. Until 2026-08-03 the `source` field was simply ABSENT from those responses, which meant a paid answer quietly dropped the one thing this service sells, and a caller could only notice by comparing keys against another response. They now carry `source: null` and a `provenance_gap` message naming the limitation. We chose to keep serving them rather than withhold them: each is dated and we believe each correct, and removing real coverage over a metadata gap would help nobody. But they do not carry the evidence the rest of the dataset does, and you should not treat them as if they do. Separately, historical rows generally do not carry a `confidence` level; we deliberately do NOT inherit the current value's, because that would assert a verification standard nobody applied to the older figure.

Instrument: (none — that is the finding)

Check it yourself: Request GET /v1/gb/vat?as_at=2010-06-01. The response carries source: null and a provenance_gap message. Compare against GET /v1/gb/vat, which is fully cited.

We returned HTTP 500 on two countries for part of a day

What was wrong: A guard added to stop working-days selling wrong answers past our calendar coverage did not account for holiday entries with a deliberately null date (ungazetted placeholders). Sorting put null last and the coverage computation threw. Trinidad and Guyana returned 500 until it was fixed. The guard itself was correct and necessary; the null-handling was not.

Instrument: (internal — commit 8087e21 through d4dc14b)

Check it yourself: POST /v1/answers/working-days for tt or gy. It now refuses or answers, never 500s.

What changed so these are caught sooner

The costliest errors we have found share one cause: a value that was correct when written and was invalidated later by a new instrument. Freshness checking cannot catch that, because the value never changed — what changed was the world. Two things now run against it:

Neither is sufficient. Both are better than a last_confirmed date that only says someone looked.

Found something wrong?

Send the instrument. [email protected] — corrections with a primary source are acted on and credited here.