Comment by throw0101c
13 hours ago
Perhaps the auditing needs to be done on the workflow process and once the automated code is in place there needs to be a traceable chain of modifications to it that need to be justified.
The "audit" certifies a certain hash of a repo that produces known-good results, and if you use a different commit in that repo you have explain in an SEC filing why you modified things.
Basically reproducible builds for financial results:
I know a few accountants, and I do not think this is possible. There is an incredible amount of manual adjustments that have to occur to get the books in order. I suspect the official process is 100% GAAP approved and great, but the messy reality has thousands of tweaks that were massaged all over the place to correct for one thing or another.
Yes, I know some accountants as well, as well as bookkeepers who have to do adjustments for things like 'timecards' and punching-in and -out: there's all sorts of adjusting that needs to be made.
But any "mistakes" that are made are simply corrected the next reporting period (whether that's monthly, fortnightly, weekly, or daily) in this more-frequent proposal.
The 'crunches' that occur at quarter/period-end are there because there is so much attention put on those reports because they're so infrequent. If the sampling rate is higher then errors are corrected that much sooner.
The reports are generated on the books in the state that they currently are in on a monthly/fortnightly/weekly/daily basis, and any adjustments will be "fixed" in the next reporting period. The reason why there's so much pressure to get them "correct" now is because of the (relatively) infrequent reporting. If you know that things will be 'sorted out' in a fortnight (two weeks), or whatever, there's less pressure now to get them "right".
There will be an expectation of less perfecttion and more corrections and better 'smoothing' due to the higher 'sampling rate'.
Isn't that the kind of toil that tends to get automated away with CI/CD?