My point is that if Excel spreadsheets can be audited, practically speaking, why are these major errors going unnoticed all the time?
Edit: My contention is that spreadsheets are in fact, very opaque, and it is incredibly difficult to check that every part of a spreadsheet is actually doing what its users think it is supposed to be doing. Specifically, I posit that it is harder to check a spreadsheet, than it is to check a "traditional" program in a normal programming language, which works on pure data.
> Specifically, I posit that it is harder to check a spreadsheet, than it is to check a "traditional" program in a normal programming language, which works on pure data.
I don't think I can agree with this. The average codebase I see is pretty terrible readability-wise. Nasty levels of function nesting, tons of variation of behavior based on arguments passed into functions, etc. I assume the average Excel spreadsheet is also pretty nasty, but it has the advantage of having a debugger "built in" vs looking at the code generally without actually seeing the data flowing through it (e.g. who runs every code review they do through a debugger?).
I also think this ignores that a "traditional" program replacing Excel would still need to get data from somewhere, which commonly implies a SQL database or a data warehouse that speaks SQL these days, and complex SQL is itself NASTY to verify/fully grok through reading alone.
My main problems with checking spreadsheet code are:
1) Code formatting - spreadsheet formulae are generally presented all on one line with minimal spacing and no syntax highlighting. Any mildly complex formula should ideally be presented a) across multiple lines, b) with indenting to show function nesting depth, and c) in colour.
2) Copy and paste - spreadsheet formulae are generally copy-and-pasted every time they're used (i.e. on every row), rather than being defined once and referenced in each place they're used. Some spreadsheets are now good at highlighting if one formula is out of place in a column of otherwise-similar formulae, but it's hard to check if formulae are supposed to be "the same" in different columns, or different worksheets, or in different spreadsheet files.
I've been involved in at least a dozen audits during Series B/C fundraising periods, the bulk of which included financial models with forward-looking quarterly forecasts backed up with prior-quarter actual results.
Accounting audit usually involves accountants/CFO going through how the accounting system accounts are structured, and how those accounts get turned into the three financial statements (cash flow, income statement, balance sheet). You might have a unique accounting scenario where large expenses can be amortized over several periods, and an auditor will check how that reporting schedule was produced to net out what everyone is looking at on the financial statements. Maybe there was an acquisition that didn't quite pan out and there's an impairment charge that had material differences. Maybe your business collects cash upfront but reports deferred revenue. Maybe your company offers a product warranty so there's a non-trivial accrual schedule to consolidate warranty liability.
I worked at a company that convinced the SEC that it generated revenues from its published content over a 5-year period, allowing it to amortize expenses over that revenue-generating period while front-loading revenues over the first 18 months. Eventually the SEC changed the rules and expenses were expected to be reported in proportion to revenues.
There's a lot of ways those numbers can be put together, with a lot of different rules for how cash, revenue, and loss can be represented and disclosed. The kinds of errors I've seen encountered are less Excel formula errors, and more fundamental issues with account structures and how numbers are being strung together to reach what is reported.
The impression I've received is that what matters during the audit process is not if there are mistakes and errors, but if they lead to material changes that alter the trajectory of any decisions being made.
OK, I can see I've been talking somewhat at cross-purposes to some other people in the thread. When the G*P commenter said:
> The killer feature of Excel for financial modelling, over 'proper' software, databases etc is portability and auditability.
...comparing Excel to "'proper' software", extolling Excel's "portability and auditability", I read that as highlighting Excel spreadsheets' ability to be audited as software.
i.e. the ability to inspect the "code" of a spreadsheet, to ensure it does what the authors think it does/want it to do, and that it conforms to any informal/internal guidelines of the organisation using it - the sort that "'proper' software" is subject to.
That seemed to me to be the meaning intended by the original comment in the thread?
The kind of professionals doing audit's against Excel spreadsheets are not auditing the "code", they're auditing the methodology used to produce the results being audited.
I've also been through several code audits, and other than sharing the "word" audit they're not the same thing. Audit in this context is the ability to follow how some numbers were derived, and to check how the work was done. It's so that the 3rd party that hired them can confirm the numbers a 1st party are showing are what they say they are (and if not, are they close enough).
Accountants are confirming things comply with GAAP or IFRS, and pointing things out when they don't and asking for clarification. They'll be checking that liabilities were properly structured, and reflected in how profit was derived. They'll be reviewing deferred revenue schedules to make sure next year's pre-paid subscription revenue isn't recognized in Q4.
A financial auditor is going to be looking at the assumptions of the forecast, and working backwards to confirm the methodology. They'll confirm that Q4 2026 projections used the prior years average multiplied by quarterly constant. Or they'll find a results from an ARIMA/Prophet model with notes to "see X". Maybe they'll catch an Excel formula error or 2, but they'll unlikely mean much compared to what else could be wrong.
Because not all spreadsheets are audited? Just because they can doesn't mean they are. Also a financial audit is very different in what it is looking for, compared to a cyber security audit, for instance. They are looking to prove the accounts show a true and fair view of the company, not 'are your formulas perfect'. They are more likely to copy out your raw data and run their own analysis.
Answering your edit, not all spreadsheets are opaque either. We design ours to be audited.
Auditors don’t show up to critique your formulas. They are looking at business processes, which means usually the data that flows between things. If it gets to the point where they are digging that deep, they have a finding and are trying to assess the severity.
Software, including major business systems are often fucked up. There are major companies using RPA software to robotically use excel to correct some fubar in Oracle financials that wont get fixed for a few years.
The beauty of excel is that the business speaks it.
Edit: My contention is that spreadsheets are in fact, very opaque, and it is incredibly difficult to check that every part of a spreadsheet is actually doing what its users think it is supposed to be doing. Specifically, I posit that it is harder to check a spreadsheet, than it is to check a "traditional" program in a normal programming language, which works on pure data.