Contractual Algorithm Patterns or Business Events
You are 100% correct. We are also talking here about legally binding financial contracts which do not allow fussing around. They can be described with well defined algorithms ab initio. These algorithms just need to be remembered as algorithms throughout the life time of the contract which brings us to your attained level if the system is set up well. If the system is set up perfectly we would even achieve 100% but since we are erring humans we can be happy with your 99.99966%.
Exactly. But I would go further and say this. If you create an inextricable mess, there is NO WAY that a computer CAN sort everything thing out correctly. Computers might be able to get 80% or 90%. But to be useful, things need to be 99.99966% correct. (Six Sigma)
I agree with the statement, that the quality of the underlying processes will be decisive. I continuously tell my AI friends in the financial sector that they should first use some NI before applying AI (the “N” stands for “natural”). Why creating first – without need – an inextricable mess and then let it sort out by a computer?
Finance is going to be completely subsumed by the Borg mind that is arising in some decentralized fashion right now.
“Weak human + machine + better process was superior to a strong computer alone and, more remarkably, superior to a strong human + machine + inferior process.”
I would definitely prefer a self-driving car that had a steering wheel so that I or my chauffeur robot could drive it if we wanted to (why should the software have all of the fun?). Similarly, I get it that small businesses and especially nonprofits are full of C and D team players who think that GAAP is a store in the mall and consistently fuck up their books, but those of us who are CPAs and work for U.S. public companies are generally A and B team players who might appreciate some additional assistance from our technology in the form of automation of simple tasks or AI capabilities for more complex tasks, but who aren’t looking to turn over the steering wheel just yet, let alone take it out completely. Also, unlike the simple use cases of small businesses and nonprofits, the complexities of a multinational company that doesn’t make widgets but rather operates in a complicated space such as my tech or biotech clients do, are not exactly use cases for full on, or even partial automation given the current state of such technology, and so it is up to people like me to keep the kluge running to crank out those 10-Ks and 10-Qs until people like you can automate the process. Speaking of my clients and 10-Ks, my 10-K season starts on Monday for a new client and I am going to be slammed and offline for quite a while and probably won’t be actively participating in these discussions much on a go forward basis.
Happy Holidays to everyone and best wishes for a successful and productive New Year.
“in theory, theory and practice are the same. In practice, they are not” (Albert Einstein)
Tom, with all due respect it seems that your approach here is similar to trying to automate self driving cars by building a robot and putting the robot into the drivers seat and letting that robot turn the wheel of the car to make it self driving. (or something like that). What I am suggesting is that you remove the steering wheel entirely.
What I am doing is trying to help you understand your thinking. It is time to thing “outside the box”. Respectfully I suggest to you that you are being constrained by “the box”. I know this because I get constrained by “the box” myself. Now, I am far less constrained by “the box” than most accountants, but I still have enough self-awareness to understand that I am still constrained by “the box”.
The point here is not about the definition of an event. That will be figured out.
The point is this: Many tasks and processes related to bookkeeping and accounting steps performed by human accountants can, and will, be automated. Full stop. This WILL HAPPEN. Do you dispute this statement?
What I am suggesting to you is that you help me communicate to people that THE KEY TO MAKING THIS HAPPEN SOONER RATHER THAN LATER IS GOOD SOFTWARE!!! The crap that software engineers are creating is caused by the mixed messages being given by accountants. Most of those accountants, I would say 95% or even higher, don’t remotely grasp what is going on. And those that do understand, the few, have not done nearly the experimentation that I have done.
Skill and experience with no experimentation DOES NOT EQUAL innovation.
Ignorance (i.e. no skill and experience) + experimentation DOES NOT EQUAL innovation.
Skill and experience + Experimentation = Innovation
Who has the “skills and experience” as related to accounting, reporting, auditing, and analysis? Accountants. NOT SOFTWARE ENGINEERS!!!!
But we NEED THE SOFTWARE ENGINNEERS to do their “stuff”.
We therefore HAVE A CHOICE:
- Force software engineers to understand the nuances of accounting, reporting, auditing, and analysis
- Learn about the things we need to be able to communicate to software engineers effectively
This is a COMMUNICATIONS PROBLEM. Very few people get that. Communication involves TWO THINGS, not one. Most people THINK communication involves only talking. But communications involves both TALKING and LISTENING.
People can learn this the hard way, by making mistakes, lots of mistakes, and figuring things out. Or, people can learn this the easy way. Pick your poison. There are no short cuts.
And don’t get me wrong. I am NOT SAYING that I have all the answers; the fact is that I know that I do not. But my questions are better than anyone else that I have ever run across.
Basically, the opportunity is unfolding and the window of opportunity is wide open. If we screw this up, it is our own damn fault.
Point taken about the overall goal and the problem to be solved, and I understand the difference between what you are describing as a “business event” or “logical business event” (or what the FASB Concepts Statement No. 6 simply calls an “event” – I guess they agree that “business event” would be redundant ; ) and a “transaction.” After re-reading the email chain, I see that Andrew was initially responding to your question in the initial email about what to call such events, and then transitioned into the discussion about sales cycle transactions, and was not referring to such sales cycle transactions themselves as logical business events. My mistake for misinterpreting his email. I would tend to agree with the FASB in calling such events merely “events.”
Tom, there is a very big difference between a transaction and a business event. Here is a really good example. Suppose you sign a loan agreement with a bank to borrow $50,000 at an interest rate of 12% paid monthly over 5 years. (Perhaps there are a few more details, but you probably get the point). That business event, which is a contractual agreement, spawns numerous transactions: receiving the cash from the bank, each repayment, interest accruals, etc.
Per your example, a business event could be different based on the policy of an economic entity.
The point here is that machines can take care of a lot of this work, particularly for smaller businesses that don’t want to pay or cannot afford an expensive accountant on staff. I cannot tell you how many businesses screw up their accounting transactions and therefore cannot make good business decisions in many cases because their information is screwy.
THAT is the problem we are solving here.
You see what I am saying? Imagine a not-for-profit that had a software application that could help it post transactions consistent with federal grant guidelines of the grants they received. Imagine how clear the communication would be if this information and other such information is communicated clearly.
If it walks like a “transaction” and quacks like a “transaction”, why not just call it a transaction? Is there such a thing as an illogical business event? (that was a rhetorical question of course, the point of which is to illustrate that any modifiers to the simple description of “transaction” are somewhat redundant and some would say wholly unnecessary). Regardless of what you choose to call it, revenue recognition (under ASC 606 at least) could potentially be triggered when goods are shipped, received by the customer, or simply “made available to them” (see snip below) depending on how the sales contract is structured/written. And those nuances are for relatively simple transactions. More complicated transactions such as those that include multiple elements/performance obligations, or that involve collaborative arrangements as defined by ASC 808, or principal/agent considerations, can muddy the waters even further. To Andrew’s point, collectibility is presumed in order to recognize revenue (under ASC 606). To Charlie’s point, accounts receivable (as codified in ASC 310) is a different bird (in keeping with my “walks like a duck” analogy) entirely if we want to separate the “sales cycle” into its component parts with respect to the individual accounting standards that apply to them (and which are reflected in the relevant XBRL “references” metada if we are trying to tie this into XBRL). If I understand Andrew’s main point however, he is referring to the complete “contract cycle” of the sales transaction, presuming such a contract were a smart contract where the recognition for the performance of each event as specified in the smart contract could be automated. Is that correct?
Logical business events sounds good to me.
Technically the sales cycle is complete when the goods are delivered and the customer is billed via accounts receivable. Then you start a new logical transaction, which is collection of receivables.
I’d call them logical business events.
Sale is complete if goods are delivered
Seller is paid by buyer
I could have this completely wrong. What I would like to do is recast that formula using the actual terms that the FASB uses in SFAC 6 (i.e. not using abbreviations). What do “I” and “NI” and “P” and “D” and “t” stand for in this equation? –
I am not associating this with Auditchain currently but would be happy to do so if given the permission (i.e. use my Auditchain email address, maybe even add the Auditchain logo). Would be happy to add the names of other contributors should you be interested.
Please send any feedback to me or this group.