Jason Morris who created Legal Blawx said, "The onus is not on the lawyers to become programmers. The onus is on the programmers to provide tools that lawyers can realistically use."
I am in 100% agreement with Mr. Morris. Also the same thing applies to accountants and auditors and others that participate in computational professional services. Accountants and auditors don't need to become programmers. There are a few accountants and auditors that need to learn how to communicate effectively with computer science professionals who build software. Once the right software exists, the average professional accountant and auditor really don't need to understand how the software actually works. They will simply use the software.
The "bolt on" software that most software vendors created was doomed from the very beginning. It saved no time at all, in fact it added MORE WORK to the task of creating XBRL-based financial reports. That is why on one is using XBRL-based digital financial reporting other than those mandated to do so.
For computational professional services to work, the process of creating financial reports must change to leverage what technology offers to make tasks and processes better, faster, and/or cheaper.
Here is one way this will likely work. Think "layers". You have a user interface layer, a logic and semantics layer, and you have a technical syntax layer. Consider the following graphic which shows this visually (click image for a larger view):
Here is an explanation of the three layers:
- User Interface Layer: The user interface layer (see here) is where the user of the application interacts with the application. The user, a nontechnical business professional, works with "logical business related things" that are exposed by the software that the business professional is very familiar with.
- Logic and Semantics Layer: The logic and semantics layer has THREE parts.
- Engine: The first part is a "logic engine" or "rules engine" (like this or like one of these).
- Metadata: The second part is the actual "domain business logic" expressed as machine-readable information (like this for US GAAP).
- Metamodel: The third part is a metamodel, in the case of financial reporting it is the metamodel of a financial report (like this).
- Syntax Layer: The technical syntax layer takes care of the physical manifestation of something like a financial report in a standard format that can be exchanged. That format could be XBRL, Prolog, RDF/OWL/SHACL or some other knowledge graph, Cypher or some other labeled property graph, CSV, SQL, Excel (see here).
Those three layers interact with one another. There is no need for business professionals to interact with the syntax layer. There is no need for business professionals to create complicated metamodels or metadata. Specialists will do that. This is not a new idea, this is simply "model-view-controller".
Per the Law of Conservation of Complexity, you cannot remove complexity from a system; but you can move the complexity. Per the notion of Irreducible Complexity you cannot simple leave pieces out and expect the system to function as needed.
The vast majority of software applications for creating XBRL-based financial reports available today are complex, hard to use kludges. Over time, this will change.
No one has put all the pieces together correctly yet. But, working prototypes and proof of concepts such as Blawx, Pesseract, SWI Prolog-based applications, commercial tools such as XBRL Cloud's Edgar Dashboard and Evidence Package, and other software help provide glimpses of how all this will eventually work.