An error in the database used to process the votes in the London mayoral elections led to the results being announced more than four hours later than planned, a London Assembly review panel has heard.

Database bug meant confusion between first and second preferences – Photo credit: PA

At a hearing today, the panel was told that because the systems provider for the count, IntElect, could not establish the root cause of the problem, it resorted to processing the data manually using Excel spreadsheets.

This meant the results of the vote were announced at 12.18am on 7 May, rather than in the evening of 6 May, as had been planned initially. The results have since been checked and confirmed by both IntElect and an independent audit process.

Related content

Cabinet Office ‘urgently’ considering options after EU referendum site crash
Councils ‘itching’ for digital approach to voter registration

Problems were first noticed at around 4pm on 6 May, when there were “small discrepancies” between the reported votes and the number of printed papers.

Steve Gowers, chief executive office of DRS Data Services, which runs IntElect, said that the team confirmed that the counting processes were accurate, and began to look for the root cause of the error but abandoned this at around 8pm.

The electronic counting process involves the ballot papers being machine read and inputted into the database, and then the votes being calculated based on first and second preference.

The team decided to create a new set of queries to allow them to use the raw data – bypassing the second step – which involved taking the data out and putting them into a spreadsheet.

Gowers said they did not run a pre-written programme to ensure there was no additional layer of complexity.

When questioned on whether copy-and-pasting into Excel was error-prone, Gowers said that they had run as series of cross-checks to ensure that the manual system was working.

He added that the equivalent of 1.2 people were always overseeing the process to make sure it was being read and entered correctly.

Gowers said that the cause of the error, which was identified after the night, was that the system was overloaded and so the code being used to identify the first and second preferences was not consistently returning them in the right order.

The review panel questioned the witnesses on the testing that had been carried out before the event, which had only tested the system with 180,000 votes – compared to the 8 million that were taken in on the day.

Gowers and returning officer Jeff Jacobs said that the system had been used in the 2012 elections and had not seen any issues, and that they had taken that as indication it could cope with the loading.

However, all the witnesses – including the members of the firm that had audited the election process and report after the count – said that the only way they could have identified the error would have been to test it at full volume, which was noted would have cost a lot of time and money.

Commenting on the hearing, Neil Kinson, chief of staff at Redwood Software, said that firms providing software for major local and national elections must “invest in tightly automated processes, such as enterprise process robotics to keep everything running smoothly”.

He added that there was a lot of reputational damage involved “if glitches in counting software continue to occur”.

This point was emphasised by the chair of the hearing, Labour London Assembly member Len Duvall.

“The damage is reputational and credibility, and as much as we have had the assurance, there will be a few saying it’s all fiddled,” he said.

The review panel is expected to publish its report next week, which is understood could include a request that IntElect reimburses City Hall some or all of the costs of the services.