5 ms·

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 under

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.

remus 2y ago
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.
- ryoshu 2y ago
  That's generally by design.
  - thfuran 2y ago
    Not generally, no.
- jimnotgym 2y ago
  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.'
lupire 2y ago
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.)
wwweston 2y ago
> 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.
- pessimizer 2y ago
  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?
  - wwweston 2y ago
    > 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.
dilippkumar 2y ago
> 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?
- danielmarkbruce 2y ago
  "guarantee" is the key word. If you get a security audit, the security auditor doesn't "guarantee" you code/application is secure.
  - MegaDeKay 2y ago
    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.

remus 2y ago

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.

ryoshu 2y ago
That's generally by design.
- thfuran 2y ago
  Not generally, no.
jimnotgym 2y ago
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.'

lupire 2y ago

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.)

wwweston 2y ago

> 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.

pessimizer 2y ago
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?
- wwweston 2y ago
  > 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.

dilippkumar 2y ago

> 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?

danielmarkbruce 2y ago
"guarantee" is the key word. If you get a security audit, the security auditor doesn't "guarantee" you code/application is secure.
- MegaDeKay 2y ago
  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.