Excel users can make mistakes, therefore Excel spreadsheets can't be audited? Is that your point?
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.
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.
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.
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.
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.
> 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.
https://en.wikipedia.org/wiki/Code_audit
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?
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.