Spreadsheet Screw-ups (or bad choice of Excel for serious purposes)

North Liberty property owners are paying a total of about $234,000 more in property taxes this fiscal year than the City Council intended because staff forgot to count money the city already had on hand.

In August, city staff realized the certified property tax rate for fiscal 2022 — which began July 1 — was 19 cents higher than what the North Liberty City Council intended. The council had agreed to a city tax of $11.32 per $1,000 in taxable property value, but instead a rate of $11.51 per $1,000 was certified.

Due to a spreadsheet input error, the city’s reserve funds were not applied as intended, City Administrator Ryan Heiar wrote in a memo to council members.

mmm manual processes…

Thought of you guys.

…He recalled that a colleague once described to others that Sutter “built the most ridiculously complicated Excel spreadsheet I’ve ever seen in my life.”

1 Like

The lock spreadsheet unfortunately doesn’t always work.

For our annual budgeting process, us in the actuarial department will send out a template to sales which requires them to key in monthly sales figures for 1-year and annual figures for the following 4 years.

We of course locked the spreadsheet, leaving only the cells they were supposed to key in.
For some reason we got requests all round to unlock the spreadsheet. We were a bit wary but the Appointed Actuary went “fine, no reason to keep secrets” and we released the passwords with some misgivings.

When I got the spreadsheets back, I noticed that for one of them, the sum of the monthly sales figures doesn’t equal the annual figure reported (which in the original locked spreadsheet was of course just a simple SUM). The cell with the annual figure was overridden with a hardcoded number and the monthly numbers didn’t sum up.

I rang up the department asking them which was correct - the monthly numbers or the annual numbers? I got a pretty patronising “oh, so you guys made a mistake in your spreadsheet”. I would have screamed at that guy, if only he wasn’t an SVP and me a mere junior manager…

5 Likes

Solution: Any locked documents you send, macro to allow to it be unlocked with a locked cell with bold red text containing, “This document was unprotected by XX on date XX at time XX and no longer belongs to the original creator.”

2 Likes

Maybe it’s just me, the idea of having 180 linked spreadsheets seems just a tad risky.

We really need the :yikes: emoji.

:astonished: just doesn’t cut it.

2 Likes

Actually despite my “yikes” reaction… for years I did maintain a spreadsheet that linked to a crap ton of other spreadsheets now that I think about it.

We were basically managing claims in Excel and had a summary spreadsheet that pulled the totals from all of the others.

I’d regularly point out to auditors how not secure that was and how easy it would be for me to defraud the company of several million dollars before anyone figured out what I was doing. And how easy it would be to migrate the claims to an actual claims system with safeguards preventing that sort of fraud. Took them about 10 or 12 years to finally get around to it.

1 Like

When they finally did, it probably only took them about five minutes to fix it.

I doubt it.

But the people throwing up the roadblock probably spent less time on fixing it than they’d spent on justifying why they weren’t going to fix it over the years.

That’s not saying much though.

Also, that was (what I thought was) obvious hyperbole from well over a decade ago. Maybe consider getting over it.

1 Like

https://www.theregister.com/2021/06/02/uk_special_forces_data_breach_whatsapp/

got both of these thanks to the Modeler’s Miscellany:

Oldest spreadsheet error

(that we know about)

Plimpton 322

https://personal.math.ubc.ca/~cass/courses/m446-03/pl322/pl322.html#errors

Accounting for the errors

As confirmation of both the interpretation of the table and this conjecture regarding p and q , the four apparent errors can be reasonably explained:

  • The number [9, 1] in row 9 should be [8, 1] - a simple copying error.
  • [7,12,1] in row 13 is the square of [2,41] , which would be the correct value - a mistake particularly easy to make since the squares also appear in the conjectured calculation.
  • The correct value to replace [53] in row 15 is [1,46] , which is twice the erroneous value.
  • As for the fourth error in row 2, where [3,12,1] occurs instead of [1,20,25] , there have been a couple of solutions proposed. None are entirely convincing. The possibility proposed by Gillings suggests strongly that those who made up the table had values of p and q at hand.

More on Plimpton 322:

Also, the spreadsheet was set to manual calculation and they forgot to F9.

1 Like

I am not quite sure what’s going on here.

#EndSARS panel blames computer for errors in report

The Lagos judicial panel on police brutality says the state government is trying to evade responsibility by citing computer errors in the #EndSARS report.

According to the panel’s report, protesters were killed at the Lekki tollgate on October 20, 2020 in what could be described in context as a “massacre”.

In a white paper on the report, the Lagos government accepted 11 out of the 32 recommendations of the panel, rejected one and accepted six with modifications.

The Lagos government also said the finding of the panel that nine persons died is “irreconcilable” with the testimony of John Obafunwa, a pathologist.

PANEL REACTS

Responding to the Lagos government’s white paper in a statement released by Ebun-Olu Adegboruwa, the panel said the state could have reached out to members for clarifications where necessary.

“The chairperson, all panel members and indeed the secretariat of the Panel were all within the reach of the LASG for clarifications if there was sincerity, other than picking holes in order to evade responsibility on account of computer errors and tabular alignments of cut and paste ,” the statement reads.

The panel also said the duplication of names on its list of casualties was as a result of a computer error, adding that they considered several dictionary definitions of the word ‘massacre’ before it was used.

This was a misnomer from the spreadsheet that ought to have terminated at Page 297 but mistakenly overlapped to Page 298 with the same names and same numbers ,” the panel said.

“It was the computer error of the secretariat of the panel which could have been corrected as the secretariat of the panel was domiciled in the ministry of justice at all times.

“In any event, the mere fact of repetition of same names on a table cannot without more, nullify the uncontroverted evidence of death.

“The panel considered several definitions of the word MASSACRE and adopted one of the dictionary meanings of MASSACRE as being ‘the act or instance of killing a number of usually helpless or unresisting human beings under circumstances of atrocity or cruelty’.

“The Panel considered that firing live bullets at unarmed, peaceful and unresisting protesters which led to the death of some of them, was cruel and atrocious on the part of the military and the police. The White Paper ignored these explanations and findings by the Panel.”

£46.55 million fine – and spreadsheet error was a part of it.

The notice is here:

Error 4

2.14 On 28 November 2018, the Treasury Markets team identified that a cell in the spreadsheet used for preparation of the FSA047/048 return included a positive value where a zero or negative value was expected. This was investigated by SCB, which concluded that this was caused by an error in SCB’s ILAS reporting system, which had erroneously included in the USD Gap 2 Metric client collateral held at the London Clearing House (“LCH”) but not the return of that collateral to clients (“Error 4”). Error 4 resulted in an overreporting of the USD Gap 2 Metric by USD 7.9 billion and a breach of the PRA’s Expectations (meaning this error caused SCB to fall below the USD Gap 2 Metric survival period of 91 days). SCB notified the PRA of this error on 1 April 2019, over four months after it was identified. The error was escalated to the FORC and to senior management shortly after it was notified to the PRA and was logged as a “Significant” ORE.

4.16 On 29 November 2018, Treasury Markets identified that a cell in the LMM spreadsheet (“Line 49”) was showing a positive number (around USD 10 billion), even though it related to liabilities and should therefore have been either zero or negative. Treasury Markets called GLRR the same day to discuss the finding. Following the call, GLRR emailed GFS to request a breakdown of the figure that Treasury Markets had identified as unexpectedly positive.

An £8 billion error, a £47 million fine. A spreadsheet without proper controls.

To be sure, that wasn’t the only error or lack of controls (after all, this is only error 4). But jeez.

News coverage of the fine & errors

more:

“Staff in my department have confirmed that a few values for revenues for the current fiscal year, 2021-22, on page 15, were misallocated and presented on the wrong lines,” Compton told the legislature.

“This was due to an administrative issue with a spreadsheet that was not linked to the proper columns when they were re-sorted before printing.”

She said the overall totals were correct, but the numbers in some of the columns had been misplaced. Those number corresponded to provincial tax revenues for things like the province’s gas tax, liquor tax and carbon levy.

A government staffer later told CBC News the problem was based on the province’s use of Excel to compile its budget.