Yes. Auditable in this context means something that can be examined by a financial auditor. Auditors understand and can check through Excel but they don't understand code. It is not on the auditor to guarantee that what they are looking at has no errors. Their statements on their audit reports say as much.

In my old job, we had to switch away from our working but ancient Information System to SAP for similar reasons.

While it's true that an auditor can look at an excel spreadsheet, my experience is that they'll never really understand what's happening for anything more than the most basic spreadsheets. It's far too easy to build a spreadsheet that's completely inscrutable, and you end up with an audit that's very shallow.

Then the auditor should ask you to prove it another way. You may think you hoodwinked them, but don't be so sure that they didn't build their own model to check your work... They do this all the time when people say 'I don't know how it works, the ERP calculates it.'

That's generally by design.

Not generally, no.

> Auditors understand and can check through Excel but they don't understand code.

Spreadsheets are code. Their user-facing side is a particular form of livecode oriented around "sheets"/2D arrays of data tightly connected with reactive code -- which definitely has some legibility advantages -- but they're code.

Auditability is legibility. The advantages help. But also the reasons why Excel code is legible to auditors probably have some things in common with the reasons Ruby code is legible to devs who've worked with Ruby or sufficiently-Ruby like languages: exposure, training, and culture that have coalesced around it.

And I'd guess that people who don't understand that spreadsheets are code are less likely to be able to read the limits of legibility past where there be dragons, fog, and possibly even fraud.

I don't think you get it. They can just click around and see all of the numbers and all of the formulas. You can write notes and directions into the spreadsheet to explain what it's doing. It's code and a UI.

Everybody knows it's code, I've written thousands of lines of code to back single spreadsheets. But the output is always a spreadsheet that people can flip through and check the calculations themselves if they like. It's code that outputs code. But is that a helpful observation?

> I don't think you get it. They can just click around and see all of the numbers and all of the formulas. It's code and a UI.

I'm glad you apparently agree with my statements like "Their user-facing side is a particular form of livecode oriented around "sheets"/2D arrays of data tightly connected with reactive code -- which definitely has some legibility advantages," though that agreement does make it a bit strange to lead with "I don't think you get it."

> Everybody knows it's code

When someone enters the statement "Auditors understand and can check through Excel but they don't understand code" into the discussion -- or in other words saying that an Excel spreadsheet is not code (along with asserting that's why auditors can understand it) -- apparently not everyone does know this and so it's reasonable to reassert that a spreadsheet is made of code.

> people can flip through and check the calculations themselves if they like.

If, as in any other interpreter, they understand the spreadsheet code that's being interpreted and take the time to follow what it's doing. And that's one reason why the observation that spreadsheets are code can be helpful. The distinctive visual presentation and model of spreadsheets is a legibility convenience for sure, but it can also lull people into believing they're working with something less complex than code. It helps people keep in mind that what the spreadsheet appears to be doing may different from what it's actually doing, either because the complexity has pushed it beyond casual legibility (a common problem in all kinds of code), or perhaps because someone intentionally is using the full power of an interpreted functional reactive programming language (to say nothing of VBA macros) to intentionally hide some aspect of the spreadsheet's operations. It helps people keep in mind that whatever margin of accessibility Excel's affordances provide, it still requires some of the same kind of work to audit it that other forms of code would.

You are nitpicking. I was referring to "code" in the traditional sense of C, C++, Javascript, etc contained in what are otherwise plain text files. I thought that my reference was ok given the HN audience but apparently not.

Excel supporting VBA macros blurs the lines but given that auditors spend so much time in Excel, they get to know that too. Now that Excel, has official support for Python, I suppose they'll need to have to come up to speed on that as well.

If it can be done, but not done right, that's not a big win (except in an arbitrary legal regulatory sense) than something that can be done. (And of course software "can be audited" too, by a different professional.)

> It is not on the auditor to guarantee that what they are looking at has no errors.

Um, what then is the point of an auditor?

"guarantee" is the key word. If you get a security audit, the security auditor doesn't "guarantee" you code/application is secure.

Right. It is more like a comprehensive series of spot checks. And like a security auditor, they have free rein to dig in to a particular area if they find something that doesn't smell right. I was on the Engineering side in my old job so I didn't interact with them too much, but here is one example: our company would claim depreciation on some test equipment and once I had to track down one of those pieces of test equipment and show that we indeed had the unit we claimed to have, down to the serial number. They didn't check for every piece of equipment, just the one.

Auditability is being able to back up what you claim with a record of some kind (receipt, purchase order, etc). Our QA group referred to this type of thing as "objective evidence". If your QA process says that you "shall have a design review", you need to prove that that review was held. In our case, our process said that minutes for that review had to be recorded. Our QA auditors would ask to see those minutes. Thank you ISO9001.

Spreadsheets let you click any field and understand where it came from. Excel can be thought of as an amazing post-execution debugger where you can get a previous output and value for almost any piece of memory ("cell"). I would love a debugger that could do this post-execution for some output.

Not quite the same thing but https://en.wikipedia.org/wiki/Time_travel_debugging comes close.

It's not even in the same ballpark. With excel, you are inspecting _the output_ for a specific run. There is no equivalent in modern programming.

In this case even getting 99.99% of the way there is still practically worthless, as someone will be interacting with Excel millions of times throughout a career.

Because there are so many spreadsheets? My team probably created 100 last week.

Now think of 100 pieces of software that you are confident are 100% error free?

Unless your software is formally verified how would you know?

I have to say my experience as a user has been that all software is buggy to some extent. Anyone who has worked in software for a reasonable amount of time will have found a bug in their own code that apparently worked fine, but actually was not quite right.

Would anybody on hn stand up and say that they never had a bug?

I think you misunderstand the point of the poster you are responding to.

They are trying to say that 100% error free is neither appropriate nor useful. It is a binary classification that throws away the important nuance.

That’s why they mention measures like “defect rate” and “bug severity”. Those measures are not currently being discussed here, and they should be.

> If that's the case, why do studies show that so many Excel spreadsheets have major errors in them?

Your point, which is completely true, is not incompatible with GP's statement.

Excel is ubiquitous in the corporate world and most spreasheet in the corporate world are completely full of errors everywhere.

Not just errors but also broken assumptions.

I've been tasked with porting a spreadsheet to a dedicated app because people noticed numbers were off and, oh the clusterfuck. Never again.

The world started making much more sense to me from the moment I realized most business decisions were taken based on powerpoint presentation containing numbers coming from broken Excel spreadsheets.

Financials are auditable. Code is auditable. The fact that something can be audited doesn't mean it will be, or will be done well if done.

Now do software in general.

Excel users can make mistakes, therefore Excel spreadsheets can't be audited? Is that your point?

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.

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?

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.

Sounds like you work well outside of the domain.

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 wonder if something like Lotus Improv would be easier to audit.

Software is both testable and auditable, and yet, bugs still exist! Even in open-source code which is also freely and publicly reviewable.

The ability to audit doesn't necessarily mean that the "code" in a spreadsheet is easy to read, only that it is easy to see...