Digital Financial Reporting

This is an excellent article, What are Ontologies? The article is easy to read, it explains what ontologies are, the benefits of ontologies, and the limitations of ontologies.

Don't know if people realize this, but you can embed XBRL linkbases within XBRL taxonomy schemas.  I have been doing that with my FAC schemas.  For example, see this XBRL taxonomy schema with embeded linkbases here.

XBRL Cloud has what they call their "logical model".  That comes in the form of an XML Infoset or JSON (I used a .txt file name, but this is JSON). That logical model is what drives the creation of this XBRL Cloud Evidence Package as I understand it.

The XBRL International XBRL 2.1 Conformance Suite has some tests in the 400-misc section that relate to XML containers.  This apparently (a) is standard and (b) allows you to put, it seems, an XBRL instance, all associated taxonomy schemas and linkbases, and all XBRL Formulas together into ONE FILE.

So, here is a prototype that I created that uses the SFAC 6 prototype.  Here is the XBRL instance, multiple XBRL taxonomy schemas, XBRL Formulas all combined into one file. NOTE that is not valid per the XBRL 2.1 conformance suite yet.

So, this is actually logically equivalent to above and does pull in 100% of the logical information that is necessary from a bunch of different files.  Using standard XBRL discovery rules (i.e. Discoverable Taxonomy Set, DTS) all that "stuff" is required to be combined.  Software stores all that in memory in order to work with the XBRL-based information.

Essentially, what any of these things give you is a graph that can be accessed using, say XPath, XML Path Language which is a query language for XML nodes in one document or across documents.

Another approach is GraphQL.  People seem to love GraphQL. Here is a video introduction to GraphQL.  This video explains that GraphQL is essentially an alternative to REST end points for returning information from a web server.

So here is an approach to using GraphQL-LD: Linked Data Querying With GraphQL.  This seems to enable the possibility of using GraphQL against an RDF triple store.

Pick your storage mechanism, pick your query language.  What makes this work better is if the nodes of the graph are (a) the information you need and (b) logically organized. That is where SBRM comes in.

In the US; the FDIC, SEC, and FERC have each implemented XBRL and each has done so differently.  ESMA has their own approach, using ESEF (European Single Electronic Format).  Greenfiling seems to be pushing a "Green Open Filing Metric Ecosystem" for things like climate change information. Eurofiling, which I believe helped to get ESEF created and I believe is behind Greenfiling, seems to be pushing things in the right direction. SBR (Standard Business Reporting) is another approach to business reporting. The DataPoint Model is another approach.

What would be incredibly unfortunate is if each regulator created their own custom version of XBRL-based reporting.  It is also unfortunate that there is not yet some general format that someone could just pick up and use.  That is what OMG's SBRM is trying to achieve.

Folks, every regulator consumes "words" and "numbers".  Sure, perhaps there are some good reasons to have different types of XBRL-based reporting.  But each being custom without good reason is really dumb.  Sure, the standard ISO shipping container has multiple versions.  There will likely be different versions of XBRL-based reporting also.

Regulators, think about what you are doing and how it will impact others.

Enterprises generally have multiple regulators that they have to interact with.  Enterprises are likely going to leverage digital business reporting and digital financial reporting internally.  How is what each regulator doing impacting them?

Rules prevent anarchy.  Machine-readable rules are the "orchestra leader" that keeps the instruments in harmony.  This video playlist, Rule Types Overview, helps you understand the different categories of rules and what role each category plays.

I have created an updated trial balance XBRL representation, factoring in things that I have learned since this was origionally created. (Note that this is my most current master list.)

One of the most important improvements relates to getting semantics represented correctly.  In prior versions I introduced the notion of "class-subclass" relations.  I am not calling these "type-subtype" associations per recommendations from someone.

This is what I am talking about.  Here are the type-subtype relations that I have defined in the trial balance representation in human-readable form.  In the past I only provided XBRL presentation relations.  I still provide those, but I am now representing this information using XBRL definition relations and the XBRL "general-special" arcrole.

In addition, the disclosures have improved representations.  I used to define a disclosure by simply creating an XBRL taxonomy schema like this.  But nothing really specifies that what is in the taxonomy schema is a disclosure; a machine cannot really distinguish what is in that XBRL taxonomy schema from other stuff in other XBRL taxonomy schemas.  So, what I did was define XBRL definition relations specifically specifying that those are what the conceptual model knows as a disclosure.

Those disclosures are used by the disclosure mechanics rules and the disclosure rules (I used to call this the reporting checklist).

Defining specific disclosures, providing a specification for each of the disclosures, and specifying when the disclosure is required to be provided enables the creation of processes that (a) identify disclosures in reports, (b) explicitly verifying that the disclosure is represented correctly, and (c) explicitly verifying that what has been specified as being required to be in the report is actually provided in the report.

I will explain all of this in the documentation for this trial balance representation.  If you want to follow along, watch here.