Digital Financial Reporting

This blog post strings together the steps involved in the effective automation of a record to report (R2R) process using pure, global standard XBRL for any financial reporting scheme.  This approach uses a method that leverages the Logical Theory Describing Financial Report. (Human readable | Machine readable)

Step 1: Financial Reporting Scheme

First one needs to define a specific financial reporting scheme in both human readable form and in machine readable form.  Today, financial reporting schemes are documented in what amounts to "books" so the information about that financial reporting scheme is only understandable to humans.  But, what if as much information as possible is first created in machine-readable form and then that machine-readable information is transformed into human-readable form using computer processes.

Here is a working prototype of a simple, basic financial reporting scheme that I defined to test each of these steps. I am keeping this as small as possible to make testing easy, but thorough enough to make sure I can test this entire process.  Note that the the financial reporting scheme is defined in both human-readable and machine-readable form. 

• Terms: Human readable | Machine readable
• Structures: Human readable | Machine readable
• Associations: Human readable | Machine readable
• Rules: The following categories of rules,
  • Mathematical: Human readable + Human Readable | Machine readable + Machine readable
  • Consistency cross checks: Human readable | Machine readable
  • Derivation rules: (not necessary, you control the process)
  • Disclosure mechanics: Human readable | Machine readable (example rule)
  • Reporting checklist: Human readable | Machine readable
  • Type-subtype (a.k.a. wider-narrower): Human readable | Machine readable
  • Model structure: Human readable | Machine readable
• Facts: Human readable | Machine readable (reference implementation of a report to test financial reporting scheme)
• Model: Human readable | Machine readable (directly references 100% of rules)

Today, conceptual frameworks that document financial reporting schemes are incomplete and tend to be somewhat ambiguous in some areas.  XBRL Taxonomies provided also tend to not provide all the machine-readable rules necessary.  The rules exist within the accounting and reporting literature, but if they don't exist then you must supplement the XBRL taxonomy with the necessary machine-readable rules to control the process and make sure your results are of the necessary high-quality.

Step 2: Chart of Accounts

An economic entity that reports per some financial reporting scheme needs to define the chart of accounts used by the economic entity. Then, that chart of accounts needs to be mapped to the base financial reporting scheme. 

• Chart of Accounts: Human readable | Machine readable
• Map COA to Base Taxonomy: Human readable | Machine readable (human readable XBRL definition relations for balance sheet, human readable XBRL definition relations for income statement)

Step 3: Tags or Transaction Description Codes

A chart of accounts is pretty much universal for accounting systems. Adding transaction description codes is less common.  I came up with the idea of what I call transaction description codes independently of knowing that Workday using the notion of what they call "worktags".  A transaction description code is simply a keyword or tag that enables the aggregation of general journal entries in a particular manner.

Currently, most financial reporting schemes represented using XBRL to not include this information.  My base taxonomy for this prototype does, however, include the definitions for these tags. 

• Transaction Description Codes (i.e. tags): Human readable | Machine readable

So why exactly do you need this information? The tags provide information for grouping general journal entries by the roll forward line item they relate to.  Basically, this information (note the codes) gets transformed into roll forwards: Cash and Cash Equivalents roll forward, Receivables roll forward, PPE roll forward, and so forth for every balance sheet line item.

Step 4: General Journal Entries

OK, so transactions get posted to an accounting system via general journal entries or subledgers that ultimately make their way to the general journal one way or another. General journal entries are in the accounting system but then can be exported into a number of different formats: 

• PDF
• CSV
• Excel
• Hledger (Plain Text Accounting format)
• XBRL Global Ledger

We are using the XBRL Global Ledger format but any format could be used.  All the other prior information is represented in the XBRL global standard format. 

Step 5: Report Writer

The next step is to take the general journal entries, chart of accounts, transaction grouping codes, financial reporting scheme base taxonomy, any extension taxonomy that is necessary and synthasize all that into a set of financial statements.  Processing is 100% automated.  Currently, this is a prototype created using Microsoft Access that reads the metadata and the XBRL-based general ledger transactions which then outputs a raw XBRL instance: 

• Raw XBRL instance: output from process
• Evidence package: input is raw XBRL instance, output his this human readable HTML
• Autogenerated Inline XBRL: output from process
• Pixel Perfect Inline XBRL: currently a prior version, additional metadata is necessary to generate pixel perfect rendering
• Pixel Perfect PDF Rendering: currently a prior version, additional metadata is necessary to generate this PDF rendering

Step 6: Closing Book or Standard Audit Schedules

Whether a report is "audited" by the reporting manager and team creating the report, an internal auditor that is not independent from the reporting economic entity, or a third-party auditor that is providing independent assurance as to the true and fair representation; every report needs to be verified to be an appropriate representation of information.

Standardized schedules that are autogenerated from accounting system information can be created to support a financial report. I have created an Audit Data Schedule (ADS) prototype that is intended to emulate such standard schedules provided by the AICPA, ISO, or industry groups such as Engine B. Engine B calls what they are creating a Common Data Model (CDM) for audit. (Also see here.)

• Chart of accounts: Human readable | Machine readable
• Bank reconciliation: Human readable | Machine readable
• Receivables open items: Human readable | Machine readable
• Customer master data: Human readable | Machine readable
• Inventories listing: Human readable | Machine readable
• Fixed assets listing: Human readable | Machine readable
• Accounts payable open items: Human readable | Machine readable
• Supplier master data: Human readable | Machine readable
• Long-term debt instruments: Human readable | Machine readable
• General journal entries: Human readable | Machine readable

All of the closing book/audit schedules are verified to be consistent with the autogenerated financial report.  Automated independent audit steps where not performed.

Step 7: Financial Analysis and Benchmarking of Reported Information

Finally, automated financial analysis and benchmarking steps are performed to provide an analytical review of reported information as compared to prior reports and peers to determine if there are any odd variances which should be investigated. 

• Analysis tool: Human readable | Machine readable

Please take note of the Extraction tool linked on the human readable analysis tool.

Step 8: Testing

To make certain that you are effectively controlling your process so that you generate a properly functioning financial report, you need a rules engine to process the machine readable information.  Further, the rules engine can help business users interact with the machine readable information making the tasks and processes easier to perform.

Pacioli is a platform for interacting with an XBRL-based report logic.  On top of the Pacioli platform, software engineers can create a tool for accounting professionals to interact with the information contained within an XBRL-based financial report.  Here is a prototype.  Several applications understand financial reports: Pacioli, XBRL Cloud, XBRL Query, Pesseract are a few examples.