Written by Peter Boritz     Posted on February 3, 2010

Peter Boritz is the architect and chief technical officer for Snappy Reports XBRL. He can be reached via e-mail.

Understanding Automated Data Management
It’s important to have a sense of perspective about XBRL: it is a means, not the end, of data reporting. An XBRL system is neither the beginning nor the end of a data point; instead, think of XBRL as a postal system. The starting point begins with an accounting/finance system or other data source and the endpoint is a data repository.

For regulatory filings in America, the starting point is the filer’s accounting/finance system and the endpoint is EDGAR.

EDGAR is a data warehouse that stores pertinent information for internal use and reporting purposes. It is fed from an XBRL-based receipt and validation system, and it is designed around XBRL. The data it stores is architected around US-GAAP. EDGAR’s purpose is processing and reporting filing data.

What lies between the starting point and EDGAR are the filer’s XBRL system and the XBRL receiving processes running at the SEC. Thus, the first task for each regulatory filer is to get data into an XBRL filing. Automated data management can play an instrumental role in this task.

Getting data into an XBRL filing could be a manual drag-and-drop operation using an add-on to Microsoft Excel. This method does not save mappings, though. For your next filing, you would need to start all over again.

A better approach, therefore, is bringing data in from an accounting/finance system, using an automated process. This process is designed to be seamless. Mappings are stored permanently and reused. While setting up such a system requires up-front work for the first filing, the benefits well outweigh the costs.

Event Triggers
The process of getting applicable data from an accounting/finance system or other source into the XBRL filing is triggered by an event. (Generally this event is the closing of the books.) The event triggers a data transfer to the XBRL system, which may be in the form of a direct transfer; XML, character-separated, or fixed-format data file; or an Excel spreadsheet.

How the transfer is achieved is not material — all of the above can work equally well — but the data to be transmitted must be planned in advance.

First, we must determine what data is to be acquired and transferred. Second, we need to define how to map that data to the XBRL taxonomy. Once these determinations are made, we should be able to make the data transfer, then run reports through the XBRL system in order to verify that everything looks good and is close to filing.

After the first filing, this should be a fairly quick and painless process. The first filing requires setup, mapping, testing, and quality control, but once these processes are set in place, life gets easier.

Security
Generally, an issue of data transfer is whether the origin system pushes data or the receiving system pulls it. In the case of XBRL, however, the only option is to push. The XBRL system has no basis of knowing when books have closed in order to procure a transmission. As well, it has no idea of how to go into an accounting system to get the data. There is a security issue in play: few businesses will allow a third-party vendor to reach into the guts of their accounting system to obtain information. It remains more secure, and more desirable, to prepare a push on one’s own terms.

Consistency
Here is a caveat with spreadsheets: typically, spreadsheets are embellished with reporting logic that makes them more readable, but these embellishments cause a mapping issue. What is easier for a human to read is not necessarily machine-readable.

Consider the following example. The element net property and equipment may be embellished in a spreadsheet as net property and equipment net of accumulated depreciation of $x. That may be easier to read (to a human), but, upon export, the suffix net of accumulated depreciation changes with each reporting period. Thus, we would no longer have a constant — net property and equipment — to map to.

Some reporting logic embellishments in spreadsheets can actually impede machine readability. Consider the following fragment of a spreadsheet that tracks changes in operating assets and liabilities:

Changes in operating assets and liabilities (net of dispositions and acquisitions):
Accounts Receivable
Inventories
Deferred Costs

 
A human can easily understand this: the entries for “Accounts Receivable”, “Inventories”, and “Deferred Costs” refer to changes to each of these values.

A computer cannot take this context into consideration, however. The line for changes in accounts receivable has the title “Accounts Receivable”, so a computer program could merge this with the value for Accounts Receivable. In other words, the machine would conflate the change in a value with the value itself. This is unacceptable; it should not be allowed to happen.

A better approach is directly correlating to the chart of accounts. This means that character-separated, fixed-format, or XML files are better suited as source files. These provide a consistent and direct correlation to the financial/accounting system, which makes the mapping process easier and more manageable.

Text-Based Disclosures
Automated processes work well for financial reports like the balance sheet and income statement, but disclosures present other issues. These generally come from text or “EDGARized” files.

For an automated process to work, a disclosure source file must have a consistent format. In many cases, reporting numeric facts can be automated, but text-based disclosures must be manually dragged and dropped to complete the filing.

Optimally, disclosures can go into a spreadsheet or processable data file with a heading and disclosure body. This would be machine-readable. An EDGARized file may be machine-readable if it contains consistent heading tags. Otherwise, disclosures may process from an XML or character-separated file.

Conclusion
Even considering the challenges listed here, an integrated and automated approach is the best solution for serious filers. Excel spreadsheet add-on programs simply are unable to provide automated integration to financial/accounting systems. The small investment of up-front work required to properly define the integration will quickly pay off in terms of improved functionality and reliability.        
              

Add to Del.icio.us | Digg this

This entry was posted on Wednesday, February 3rd, 2010 at 10:19 am and is filed under General, . You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.