Every percentage on this site had to get here from somewhere: an electoral commission's CSV, a results portal, a statistical office, sometimes a broadcaster's feed on the night. The transfer is where errors are born, and after a few hundred elections the errors have turned out to be strikingly repetitive. Here are the ones that actually happen, and what catches them.

Error 1: the summarised table

The most dangerous input is not a bad source. It is a good source, summarised.

Reading a results table through any tool that paraphrases it — an automatic summariser, a scraped snippet, a secondhand article — is the single most reliable way to publish wrong numbers. Columns get swapped between adjacent candidates. A row is dropped and the remaining shares silently no longer sum. A first-round figure is quoted where the second round was meant. I have caught every one of these, and the failure mode is uniform: the output is fluent, plausible, correctly formatted, and wrong.

The rule that came out of it: parse the raw table, never a description of the table. Wikipedia's raw wikitext is available on every article, official commissions publish CSV or XLSX, and both can be parsed deterministically. If the only available form of a number is prose, the number is not yet verified.

Why a paraphrase fails on tables specifically: a table's meaning lives in its structure — which column a number sits in, which row it aligns with. Rendering it as sentences discards exactly the information that made it unambiguous, and nothing in the resulting text signals that the alignment was lost.

Error 2: two denominators in one table

Vote shares are only comparable if they are shares of the same thing. Most commissions report each candidate's percentage of valid votes. Some — Russia's Central Election Commission among them — report shares of all votes cast, invalid ballots included.

Both are legitimate. Mixing them is not, and the error is nearly invisible: every number looks reasonable, the ordering is unaffected, and the shares are off by around a point each. The check is arithmetic — the shares must sum to about 100% on the stated basis, and any residual has to be explainable as "others" or as invalid ballots. Our consistency script runs that sum on every page.

Error 3: the inconsistent summary box

Encyclopedia infoboxes are compiled at different times from different sources than the detailed tables further down the same page, and the two do not always agree — particularly for elections where the count was revised, or where seat totals shifted after a by-election or a repeat vote. Israeli and Russian election articles have both given me an infobox that disagreed with the article's own results table.

The check is to prefer the most granular published figure and reconcile upward: constituency numbers should add to the national total, and seats by party should add to the size of the chamber. Germany's 2021 Bundestag is a good example of a total that looks wrong and is not — 735 seats, an unusual number that is correct because of overhang and levelling seats, and where a party's total also reflects a partial repeat election later held in Berlin. A figure that looks anomalous needs an explanation, not a correction.

Error 4: the number that is not final

Preliminary and certified figures both circulate, and the preliminary ones circulate faster and get copied more. A number lifted from an election-night article and published as final will usually be close and occasionally decisive — see why official results sometimes take weeks. Every result here is labelled with which stage it came from, and provisional figures are replaced once the certifying authority publishes.

The checks that run every time

  • Sum the shares. Candidate percentages must sum to approximately 100 on the stated basis; anything else means a missing row or a mixed denominator.
  • Sum the seats. Party seats must equal the chamber's size — including reserved minority seats, which is what makes Kosovo's 120 work out.
  • Reconcile turnout against the ballot counts. Valid plus blank plus invalid should equal ballots cast, and ballots cast over the roll should reproduce the published turnout.
  • Two decimal places, exactly as published. No rounding on entry. A figure rounded to one decimal cannot later be checked against its source, and the rounding hides precisely the discrepancies these checks exist to find.

The checks a live feed needs that a static table does not

Everything above assumes you have a finished table in front of you. On election night you do not — you have a stream of partial data from a source that may be reformatting itself as it goes, and you have to decide in seconds whether each snapshot is publishable.

Three rules do most of the work there:

  • Fail closed. If a snapshot cannot be parsed or does not validate, the page keeps showing the last good state and says it is waiting. It never shows a partially-parsed snapshot, and it never falls back to a guess.
  • Test internal consistency, not plausibility. Yes plus No plus blank plus invalid must equal the reported total. That check is decidable. "These numbers look suspiciously round" is not — I once withheld twenty-five minutes of perfectly genuine Icelandic results on exactly that reasoning, and the numbers were an official announcement. The full account is here.
  • Publish only what the source itself has concluded. No verdict and no turnout figure before the authority declares the count final, because both make claims about the whole electorate from a fragment of it.

Snapshots are also stored immutably, one file per version, so a figure that was on the page at a given minute can be retrieved afterwards. If we get something wrong on the night, the record of what was shown and when still exists — which is the minimum standard for being able to correct it honestly.

None of this is sophisticated. It is arithmetic, applied consistently, on data read in its structured form rather than described. The sophistication would be in trying to do it faster — and that is exactly where the errors come from.