WO2010111328A1 - Methods, systems, and software for processing financial documents - Google Patents

Abstract

In one aspect the invention comprises a computer-implemented method comprising electronically receiving a document comprising securities compliance data and electronically tagging terms in said document with XBRL tags, wherein said tagging comprises applying mapping lists, and wherein said mapping lists comprise a job list, a client list, a base list, and a taxonomy list In another aspect, the invention comprises a computer system comprising a processor that electronically receives data describing a document comprising securities compliance data, and a processor that electronically tags terms in said document with XBRL tags, wherein said tagging comprises applying mapping lists, wherein said mapping lists comprise a job list, a client list, a base list, and a taxonomy list, and wherein said processor that receives data and said processor that tags may be the same or different processors In another aspect, the invention comprises corresponding software stored in a computer readable medium.

Description

METHODS, SYSTEMS, AND SOFTWARE FOR PROCESSING FINANCIAL DOCUMENTS

Introduction

In recent history, financial information has been processed digitally (for example, in Excel spreadsheets or tables in a .pdf document). But this approach is highly problematic since each software application generates its output document (balance sheet, income statement, etc.) in its own format, which often cannot be read directly by a different application. Traditionally, this problem has been addressed by exporting the file in an ASCII format (a text file with each data field separated from the next by a delimiting character, such as a comma) so that it is possible to import and read the original ASCII file in another application. However, this solution can be very time- consuming since it is often necessary to modify the ASCII file when the exporting application does not use the same delimiting character as the importing application. As a result, this may cause the data to be skewed and placed in the wrong table (or incorrectly placed in the right table). Another solution is to set up a specific "translation" application to convert the data between two applications.

The need for a digital standard to exchange accounting information among software applications is even greater when the goal is to gather data points from many different financial statements that have been published in various formats (pdf, xls. html, doc, etc.). Today, there is such a standard: XBRL (Extensible Business

Reporting Language) is an XML-based specification for representing business reporting information. XBRL provides the business community with a standards-based method to prepare, publish in a variety of formats, reliably extract and automatically exchange financial report information. It provides a common way for disparate systems to exchange specific information and provides a means to separate data from formatting.

XBRL is a royalty-free technology developed and maintained by XBRL International, a not-for-profit consortium comprised of over 800 accounting, technology, financial services and regulatory-type organizations across the world. XBRL international was formed in 2001 after the initial efforts to bring the concept of XBRL to market by the American Institute of Certified Public Accountants (AICPA). Local jurisdictions such as XBRL US, XBRL UK and XBRL Canada form the basis of XBRL International membership and help drive XBRL education and adoption within a specific country.

The advantage of XBRL is that it is machine-readable, and computers can use the tags to pull out comparable data from different companies from their filings. It saves a person from having to read through financial reports to find specific data, since companies typically have different styles of presenting their financial data in reports. XBRL is used to digitally publish both internally and externally business reports such as financial statements. An XBRL-based business report is a digitally enhanced version of a paper-based report such as the Balance Sheet, Income Statement. Statement of Cash Flows and Notes and Schedules to the Financial Statements. XBRL reports can be prepared efficiently, exchanged reliably, published more easily, analyzed more quickly, and retrieved more simply.

In addition to financial statements, XBRL can be used to address the following types of business reporting: (a) regulatory filings (filings required by government and regulatory agencies); (b) taxes and tax returns (submissions that collect personal and corporate tax return information); (c) internal reporting (management and accounting reports detailing internal performance that are typically created by an accounting/enterprise resource planning (ERP)/enterprise resource management (ERM) system; (d) metric/key performance indicator (KPI) reporting (represent ratios and other key metrics/indicators to enable companies within and across industries to easily benchmark performance); and (e) authoritative literature (provides a standard way to describe accounting-related authoritative literature published by the AICPA, FASB, ASB, IAS and others).

An embodiment of the present invention comprises XBRLMark software that processes targeted financial documents into XBRL submissions for the SEC. ACE is an acronym for Advanced Composition Engine. ACE is a component of the Bowne Integrated Typesetting System (BITS) and is the part of BITS that manages positioning of characters in space. EDGAR2 is a term referring to content that is compliant with the SECs HTML specification for documents filed on their Electronic Document Gathering And Retrieval (EDGAR) system. EDG AR2 is HTML which the SEC has approved for EDGAR filings. For HTML filings, EDGAR only accepts documents that have been formatted using a subset of the HTML 3.2 semantics (tags) and some HTML 4.0 attributes, as recommended and standardized by the W3C. Due to the SECs limited support of HTML, EDGAR enforces many restrictions relative to all HTML documents that are included in an EDGAR submission. Details are outlined in the EDGAR Filer Manual section 5.2.2.

In an embodiment, the software takes ACE Typeset Format files and EDGAR2 HTML files as input and produces XBRL submissions including Tagged Instance, Schema XSD, Label Linkbase, and Presentation Linkbase files.

Microsoft Word files also can be used as input. In an embodiment, such files are simultaneously processed both as EDGAR2 HTML and XBRL submission documents.

In one aspect, the present invention comprises a computer-implemented method comprising: (a) electronically receiving a document comprising securities compliance data; and (b) electronically tagging with a computer processor terms in said document with XBRL tags; wherein said tagging comprises applying mapping lists, and wherein said mapping lists comprise a job list, a client list, a base list, and a taxonomy list.

In various embodiments: (a) said mapping lists are applied in a hierarchical order; (b) said hierarchical order is (1) job list; (2) client list; (3) base list; and (4) taxonomy list; (c) the method further comprises building a tag name automatically if no match is found in said mapping lists; (d) said mapping lists comprise mapping statements; (e) said mapping statements each comprise a tag name and a matching pattern; (f) said mapping statements are grouped according to financial statement; (g) applying said mapping lists comprises identifying a financial statement and searching mapping statements grouped assigned to said identified financial statement; (h) the method further comprises building an element tag based on an associated tag name; (i) building said tag name automatically comprises application of mapping tokens: and (j) building said tag name automatically comprises application of wildcard variables.

In another aspect, the invention comprises a computer system comprising: (a) a processor that electronically receives data describing a document comprising securities compliance data; and (b) a processor that electronically tags terms in said document with XBRL tags; wherein said tagging comprises applying mapping lists, wherein said mapping lists comprise a job list, a client list, a base list, and a taxonomy list, and wherein said processor that receives data and said processor that tags may be the same or different proces sors .

In various embodiments: (a) said mapping lists are applied in a hierarchical order; (b) said hierarchical order is (1) job list; (2) client list; (3) base list; and (4) taxonomy list; (c) the system further comprises a processor that builds a tag name automatically if no match is found in said mapping lists; (d) said mapping lists comprise mapping statements; (e) said mapping statements each comprise a tag name and a matching pattern; (f) said mapping statements are grouped according to financial statement; (g) applying said mapping lists comprises identifying a financial statement and searching mapping statements grouped assigned to said identified financial statement; (h) the system further comprises a processor that builds an element tag based on an associated tag name; (i) building said tag name automatically comprises application of mapping tokens; and (j) building said tag name automatically comprises application of wildcard variables.

In another embodiment, the invention comprises an apparatus comprising: (a) software, stored in a computer readable medium, that electronically receives a document comprising securities compliance data; and (b) software, stored in a computer readable medium, that electronically tags terms in said document with XBRL tags; wherein said tagging comprises applying mapping lists, and wherein said mapping lists comprise a job list, a client list, a base list, and a taxonomy list. In various embodiments: (a) said mapping lists are applied in a hierarchical order; (b) said hierarchical order is (1) job list; (2) client list; (3) base list; and (4) taxonomy list; (c) the apparatus further comprises software, stored in a computer readable medium, that builds a tag name automatically if no match is found in said mapping lists; (d) said mapping lists comprise mapping statements; (e) said mapping statements each comprise a tag name and a matching pattern: (f) said mapping statements are grouped according to financial statement; (g) applying said mapping lists comprises identifying a financial statement and searching mapping statements grouped assigned to said identified financial statement; (h) the apparatus further comprises software, stored in a computer readable medium, that builds an element tag based on an associated tag name; (i) building said tag name automatically comprises application of mapping tokens; and (j) building said tag name automatically comprises application of wildcard variables.

Brief Description of the Drawings FIGS. 1 and 2 depict exemplary interfaces for selecting a template.

FIGS. 3-6 depict exemplary interfaces for selecting an input file.

FIG. 7 depicts an exemplary interface for selecting processing options.

FIG. 8 depicts an exemplary display regarding processing status

FIG. 9 depicts an exemplary pre-process completion display. FIG. 10 depicts an exemplary XMK file.

FIGS. 11-13 depict exemplary interfaces for saving and processing an intermediate XMK file.

FIG. 14 depicts an exemplary post-process completion display.

FIG. 15 depicts an exemplary interface for selecting an output display. FIG. 16 depicts an exemplary browser output display.

FIG. 17 illustrates an exemplary tagging hierarchy.

FIG. 18 depicts an exemplary error message display.

FIG. 19 depicts an exemplary computer system that may be used with an embodiment of the invention. Detailed Description of Exemplary Embodiments

An exemplary embodiment of the present invention comprises software (referred to herein for convenience as "XBRLMark") that may be a Microsoft Windows application and preferably comprises a "GUI" (Graphical User Interface) that runs a plurality of smaller program modules, which preferably run as batch processes in the background.

These batch programs may be used outside of the XBRLMark application and repurposed for use as a conversion/transformation engine operating as a background task to other applications. In an embodiment, XBRLMark is a template-driven application, in that there are several supplied templates that can be cloned and customized by a user, either to address different document types or special customer needs.

Each template has an associated settings file called a Boilerplate file, in which a plurality of settings can be changed, to alter the behavior or the final output result. This may be carried out by a trained template person. This customization or set-up provides automation capability for a client's work, which may be processed on a repeat basis.

In an embodiment, XBRLMark is supplied with three or more base (or master) templates: for example, one template for accepting client- supplied Word files as input; one for accepting ACE Typeset files as input; and one for accepting EDGAR2 as input. XBRLMark may provide additional templates to address specific form types (e.g., 10- K, 10-Q, 20-F, etc.).

Basic Operation

In an exemplary embodiment, a user first selects an appropriate template from a "Templates" menu (see FIG. 1) - depending on the type of file to be processed. When the user clicks "Select" she is presented with a list of Templates from which to choose (see FIG. 2).

Once the appropriate Template has been selected, the user then selects the "Input" menu, and selects "Prepare and Open" (see FIG. 3). The user is then presented with a dialog, where she can either type in an input filename to be processed, or select from a list of files, by hitting a button 410 to the right of the Filename field (see FIG. 4).

If selecting the file with button 410, the user is presented with a dialog showing all the available input files (see FIG. 5). The user then chooses the desired file.

Once the user has selected the input file to be processed and clicked "Select," a dialog is opened (see FIG. 6). Once the user selects a "Prepare" button 610, the first of the batch programs is launched, which searches the input file for a client name. If a client name is found, the fields of an XBRL Processing Options dialog are automatically populated, and the dialog is presented to the user (see FIG. 7).

The user then has the opportunity to either accept all of the automatically selected options, or to make changes as appropriate. When the user is satisfied that all options are correct, the user selects a "Continue" button 710. and a further series of batch modules is launched in the background. In an embodiment, all that the user sees at this point is a progress control showing which particular batch module is running, and how far through the process the user has progressed (see FIG. 8).

After all the batch modules have run, a Completion dialog, which summarizes the results of the "Pre-process," or "Prepare and Open" stage, is presented to the user (see FIG. 9). This lists which Financial Statements have been selected for final processing, and how many, and which "Notes to Financials" text blocks have also been selected for final processing.

When all the batch modules have finished, they produce an intermediate file called an "XMK" file. Once the user has seen the Completion dialog, he can hit an "OK" button 910, which will then cause an XMK file to be displayed in an Edit screen (see FIG. 10). The user can review this intermediate file to verify that all required Financial Statements and Notes to Financials data have been recognized and "marked" for final processing. If the user sees any inaccuracy(s), he can re-"mark" the appropriate data correctly. Once the user is satisfied that this intermediate XMK file is correctly marked for final processing, he selects a "Save and Process" option from the "XMark" menu (see FIG. 11). The user is then presented with a further dialog, where he clicks a "Process" button 1210 (see FIG. 12). XBRLMark then launches the "post- process" - a final set of batch programs (see FIG. 13).

Once the final "post-process" has completed, software of an embodiment will display another Completion dialog, which summarizes the results of the final processing (see FIG. 14).

After the user has read the results, she may select an "OK" button, which will show a further selection dialog from which the user can choose whether to look at the final output either in a text editor, or in a browser (see FIG. 15). If the user elects to see the results in a browser, a browser will automatically open and display a resulting XBRL tagged "Instance" file (see FIG. 16).

Matching/Mapping process

As the post-process software of an exemplary embodiment runs through each line item of each Financial Statement, it extracts the "stub" language as a text string, and prepares it for parsing against one or more databases or lists.

Each of the databases or lists preferably contains a hierarchical list of "mapping statements", each of which preferably comprises two components: a search pattern (against which each stub of each line item of each financial statement is parsed), and a corresponding Tag name. If the text string extracted from the "stub" language matches the search pattern of one of the mapping statements, that is considered a "match," and that corresponding Tag name is used to form the basis of the Element tags that are applied to each data point or figure in the adjacent figure columns of that line item in the Financial Statement (see FIG. 17). Once a match is found, several other pieces of contextual information found in or around the Financial Statement may be used to complete the "attributes" of each

Element - and the final tag is constructed for each "data point." Here's an example:

<us-gaap: Invent or yNet contextRef="BalanceAsOf_30Sep2007_Unaudited" unitRef="USD" decimals="-3">26074000</us-gaap : InventoryNet> <us-gaap: Invent or yNet contextRef="BalanceAsOf_31Dec2006_Audited" umtRef="USD" deciraals="-3">25591000</us-gaap : InventoryNet>

Batch processing - "Pre-process" and "Post-process"

In an embodiment, apart from the GUI operation, all the actual conversion from an input file through to the final XBRL tagged "Instance" file is achieved via the aforementioned "batch" programs which run in background mode. There are several of these Batch programs, arranged loosely into two groups.

The first group is the "pre-process," which prepares the data for use in the intermediate XMK file format that can be reviewed by the operator. The second group is for the "post-process," for the stages when the user has reviewed the XMK file and wants to process the data through to the final XBRL tagged "Instance" file.

The batch programs can all access the Boilerplate file and if necessary use designated "settings" to change the way the program processes the data. This is part of the "pre-engineering" process. The list of batch programs used changes sometimes dependent on the Template that was selected, because certain templates require different processors in order to process a different input file format.

ACE Input Template "Pre-process"

For example, to process an ACE Typeset file, the pre-process may use the following batch programs:

1. acein.exe a. This program checks the selected input file to ensure and verify that it is an ACE typeset file; b. copies its corresponding E2 HTML version into a standard filename "e2copy.tmp"; and c. hands off the output to the next program in the chain.

2. prexb.exe a. This program checks the input from the previous program, and searches for a valid client name; and b. supplies that information to the next program in the chain. 3. xib_xbrlmark.exe a. This program takes the company information supplied by the previous program, looks up the required default data stored for the named client, and presents that data as default selected options in the XBRL Processing Options dialog.

4. startxb.exe a. This program takes the options selected by the user in the previous dialog program and generates some tagging which contains the necessary information for subsequent processing and which will eventually be displayed in the XMK file at the end of the "pre-process" run.

5. prsnr.exe a. This program is run on the file supplied as modified input by the previous programs in the chain. b. This program looks up some user-defined search/replace patterns ("SNR") previously specified and stored by the template specialist in a "boilerplate" file and replaces, removes, or inserts data, according to the user-defined search/replace patterns. c. This is part of template "pre-engineering" or "pre- flighting." d. This results in a further modified version of the input file, to be handed to the next processor in the chain. e. The primary function of this program is to allow the user to insert what "marks" or "Area Markers," which provide the automated means of recognizing which chunks of data (e.g., Financial Statements, etc.) are to be processed through to XBRL tagging. This is "pre- engineering" of the automation process. 6. stag.exe

7. This program provides the user with the ability to further "pre-engineer" or "pre-flight" the automation process, and to clean up some of the data contained within the "Area Markers" previous inserted by prsnr.exe. 8. e2rip.exe a. This program checks the previously saved E2 HTML version of the ACE input file, detects where "Notes to Financials" data is located, and individually "marks" or "area marks" each Note Title and Note Body. b. This program also merges the modified ACE typeset data with the E2 HTML version of the data to produce a whole file which contains both the ACE version with "marked" Financial Statements and the HTML version with "marked" Notes to Financials.

9. acln.exe a. This program looks through the modified ACE input data and "cleans" it - i.e., corrects inconsistencies, etc.

10. renum.exe a. This program will renumber multiple same type tables - e.g., Balance_Sheet_#l, Balance_Sheet_#2, etc. 11. xmprertf.exe a. This program takes the text data generated by the previous pre-processors and renders it into an RTF text editor format for review and possible correction by the user in the "XMK" editor. b. XBRLMark then opens up the result of this file, inside its internal XMK Editor.

The user may review, and if necessary adjust, the XMK file. ACE Input Template - "post-process" 1. pxtag.exe a. This program further simplifies and standardizes the data found in the XMK file, to prepare it for the next program in the chain; 2. xtag.exe

This program is the "main event" of an embodiment, since it performs the XBRL tagging of data. This program: a. reads the input data stream and identifies and stores information for use during processing of the required Financial

Statements; b. recognizes each delimited and "marked" Financial Statement; c. reads the "Boxhead" information and converts it into a format that can be used for tag building during processing; d. identifies and reads each table row (line item) of each Financial Statement; e. breaks the table row down into "stub label"¹ and associated "data points"; and f. parses the "stub label" text through a series of pre- engineered "Mapping Lists."

These Mapping Lists contain look up tables of "stub text" search strings, with associated "Tag Names" for building the eventual XBRL Element Tags. The Lists are in order of precedence and may have been "pre-engineered" or "pre-flighted" by a template specialist, perhaps in consultation with the client, g. The Lists are: i. the Job List (current job being processed); ii. the Client List (pre -determined standard Mapping Statements, to be used to process all that client's work;

¹ A stub label is the contextual/text-based portion of a row on a financial statement; for example, a common row on a financial statement looks like this:

Cash and cash equivalents 34 68

The "stub label" in this example would be "Cash and cash equivalents" while the "data points" would be 34 and 68, respectively. The "stub label" provides insight into the "accounting" that goes into this row and therefore is important to finding the correct association in the taxonomy.] iii. the Base List - a context sensitive and intelligent set of Mapping Statements to be used for the "Form Type" being processed by the individual template (e.g., a 10-K or 10-Q). These "intelligent" mapping statements are built on rules supplied with whichever given "taxonomy" is being adhered to at the time. iv. The Taxonomy List is a standard set of Stub label text strings, and associated Tag Names. There is no contextual intelligence built into these mappings; they are simply copied from the taxonomy being adhered to, rather like a set of "fall back" defaults for the case in which the previous three more intelligent lists fail to produce a match, h. If none of the four lists produce a "match" to the stub label text being parsed - then internal "AI" logic kicks in, which uses all the information supplied in the data, to "build" a tag name automatically; i. This automatically built tag name may later be modified by a template specialist if required, since a matching "Mapping Statement" is also automatically generated and appended to the "Job List." j. xtag.exe also examines the "Notes" data and renders the

"marked" or delimited HTML data into "Escaped HTML," which is a version of HTML that can be displayed as a string of codes inside a Browser. k. The individual "Notes" are also parsed through the four lists to find a match and again, if no match is found, xtag.exe s internal

"AI" logic "builds" a tag name automatically.

1. All other required sections of the final XBRL "Instance" file are also computed and generated by xtag.exe' s internal "AI" logic; and the entire Instance file is assembled. 3. xmlend.exe a. This is the final post-processor, which takes the previously processed data from xtag.exe, renames it to the final output name, and places it into a designated Output directory. E2-only Input Template

An E2-only template of an embodiment contains batch programs similar to those of the ACE template, except that in the Pre-process stage, some batch programs convert the financial tables from HTML to "basic ACE" format and convert other HTML code to the ACE equivalent. Otherwise the processing is similar to ACE processing, as will be understood by those skilled in the art.

Client-supplied Word Input Template

A Word template of an embodiment contains different programs in the Pre- process phase- the software pre-converts Microsoff's RTF format into an XMK file. This template also contains additional programs in the Post-process, which convert the XMK data into E2 HTML, and into XBRL tagging simultaneously. XBRLMark Mapping

When XBRLMark processes data, it identifies or "marks" the relevant Financial Statements and other sections of the job to be processed (e.g., Notes), and then extracts and tags the pertinent data. When the software extracts each table or financial statement and each data row in each table, or other designated section of the job, it looks through the four pre-existing mapping lists:

The 1^st is the active "Job List"; the 2^nd is the client- specific "Client List"; the 3^rd is the template- specific "Base List"; and the 4 is the "Taxonomy List. Typically an expert user, perhaps in cooperation with a client, will have "pre-engineered" the mappings based on feedback from the client and their previous filings.

XBRLMark searches each of the four lists (which typically contain pre- engineered mappings for a particular client) and if it finds a match uses that match to process the data points in that data row. Mapping statements:

Element tag names are associated with data points extracted from Financial Statements via "mapping" a "Stub Label" to the associated Element "tag name."

An XBRLMark "mapping statement" has two parts - the "tag name" to be applied, followed by the "matching pattern" that looks for a "Stub Label" or data row to be matched. The two parts of the mapping statement preferably are separated by "pipe" characters. An example is:

LossFromDiscontinuedOperationsNetTax | Loss from discontinued operations , net of tax | { Element tag name } {

Matching pattern / Stub Label }

Mapping lists

Inside the first three lists used in an embodiment (i.e., Job List, Client List, and Base List), each Financial Statement has its own group of mapping statements. For example, there may be different mapping statements for the Balance Sheets, versus the Statement of Cash Flows:

Table=BALANCE_SHEETS

I PrepaidExpensesOtherCurrentAssets I Prepaid expenses and other current assets I I LiabilitiesHeldForSale I Liabilities held for sale

Table=STMNT_CASH_FLOWS

INetLossFromDiscontinuedOperations I Net loss from discontinued operations

I Amortization | Amortization |

Matching process When a data row is processed, depending on which Financial Statement it came from, the software searches for the mapping statements that were designated for that Financial Statement. Each time an XBRLMark process of an embodiment runs, and each time a data row is processed, those four lists are examined, in that order of precedence, to find a matching "mapping statement." The software of an embodiment searches through each of the relevant mapping statements in the "Job List," and if it does not find a match there, it will look through the relevant statements in the "Client List", then the "Base List", then the "Taxonomy List." If it finds a match in any of those lists, it builds the Element tags, based on the associated Tag name.

If it does not find a match in any of those lists, it builds one (as described below). Pro gram- generated tag names and mappings

XBRLMark will build a tag name, based on the Stub Label and its context, and it will build an appropriate and associated mapping pattern and append that to the "Job List" for re -use on subsequent processes - see further description below.

XBRLMark Automation via pre-engineering and Advanced "Mapping Language"

XBRLMark Mapping Language

As mentioned above, there are occasions where one needs to use the built-in "mapping language" in order to precisely map element tags and stub labels - particularly where there is some ambiguity. If the Stub label is unique, and not likely to be duplicated in the same XBRL

Instance, then it is straightforward to create a mapping. For example, if the Stub label was "One of a kind", and that was the only instance likely to be found in the document, then the user could create a simple mapping:

OneOfAKind l One of a kind However, if there were likely to be multiple instances of Stub labels with the same text string (or there were "stub-less" data rows - for example, totals), then the user would need to find some way of distinguishing those data rows so that unique Tag names could be applied. This is where XBRLMark"s Mapping Language, consisting of "Mapping Tokens" and "Wildcard variables."can be used to great effect. Mapping tokens and wildcard variables

In an exemplary embodiment, four "mapping tokens" are used. These are: { all="..." } {head="..." } {prevstub="..." } {total }

There are also seven "wildcard variables": <month> <amount> <year> <date> <*> <+> <=>

The mapping tokens and wildcards listed above are mostly used in the right hand side of the mapping statement (known as the "matching pattern" or "stub label"), except for the <+> and <=> wildcards.

{head=" "} token

The Heading token is only used in the string part of the pattern (2nd part), such as:

OtherAssetsNoncurrent | {head="0ther noncurrent assets: "}0ther<*> | I PropertyEquipmentSubtotal | {head="Property and equipment"}!

The specific heading data is enclosed in double quotes inside this wildcard. This token can be followed by additional stub data or no data:

1. When {head=...} is followed by stub data: When the heading is found in a financial statement and that heading is followed by the specified stub data, the associated XBRL tag is inserted in the XBRL element for the figures for that stub. For example:

OtherAssetsNoncurrent I {head="Other noncurrent assets : " }0ther<*> | This means:

• Find a Stub label that begins with string "Other", and can have any following text in string; preceded by

• a heading with the text string "Other noncurrent assets:" Or: I OtherNoncurrentLiabilities I {head="Other liabilities : " } 0ther<*> | This means:

• Find a Stub label that begins with string "Other", and can have any following text in string; preceded by

• a heading with the text string "Other liabilities:" 2. When {head=...} is not followed by stub data:

When the heading is found in a financial statement and figures below that heading does not have any preceding stub data, the associated XBRL tag is inserted in the XBRL element for the figures. For example: I TotalExpenses | {head="Expenses : " }

This means:

• Find a Stub-less data row; preceded by

• a heading with the text string "Expenses:"

3. The {head=...} token for multiple headings: When there is a need for a mapping to reference multiple previous headings found in a table or financial statement, then multiple head strings can be separated by double quotes. For example:

TotalCurrentLiabilities I {head="First specified heading""Next consecutive heading" }|

This means:

• Find a Stub-less data row; preceded by

• a heading with the text string "First specified heading"; then

• find a next heading with the text string "Next consecutive heading".

4. The {head=...} token for multiple headings with wildcard separators: When there is a need for a mapping to reference multiple previous headings found in a table or financial statement, but where those headings are not consecutive (i.e., could be separated by other headings), then multiple head strings can be separated by an asterisk wildcard (e.g. *) that means: find the first specified heading, then any number of intervening un-specified headings, followed by the second specified heading. For example: I TotalCurrentLiabilities | {head="First specified heading" * "Next heading after intervening headings " } This means:

• Find a Stub-less data row; preceded by

• A heading with the text string "First specified heading"; then • find any intervening headings; then

• find a heading with the text string "Next specified heading after intervening headings".

5. The {head=..J token for multiple headings with internal wildcards and wildcard separators combined: Each heading string specified inside a {head=... } token, can contain wildcard variables to allow for subtle variations in the text string of the head - e.g. <*>, And furthermore, these can be combined with the asterisk wildcard separating the individual headings. For example: I TotalCurrentLiabilities I {head="First specif ied<*>heading" * "Next specif ied<*>heading" } | This means:

• Find a Stub-less data row, preceded by

• a heading that starts with "First specified" and ends with "heading" but which can have other text in the middle of that string; then

• any intervening headings; then

• a heading that starts with "Next specified" and ends with "heading" but which can have other text in the middle of that string. Example 1:

OtherAssetsNoncurrent I {head="Other noncurrent assets: "JOther

OtherNoncurrentLiabilities I {head="Other liabilities: "}Other I

The 2 patterns above are needed since "Other" stub data was found twice in the following financial statement, preceded by specific heading data:

Other noncurrent assets:

Goodwill 35,301 30,521

Intangible assets, less accumulated amortization of $1, 780 (2007) and $552 (2006) 10, 035 4, 494

Deferred income taxes 21, 682 37 , 430

Other 14, 229 10 ,113

Total assets ^~$^~~~~49^~7^~,^~73^~5 $ 516, 243

LIABILITIES AND STOCKHOLDERS" EQUITY

Other liabilities: Long-term debt B net of current portion 75, 986 76, 492

Deferred employee compensation. 34,938 52,509

Deferred rent 17, 691 22,199

Other 738 1,281

Example 2:

OperatingExpenses | {head="Expenses : " } The above pattern is needed for the following table:

Expenses :

Cost of revenue (118, 442; (115, 890)

Selling and administrative (53,543) (51,3 26)

Purchased in-process research and development ^θ 43

Example 3:

RealEstatelnvestmentPropertyNet | {head="Real Estate, at cost"} {prevstub="Less : accumulated depreciation"} us-gaap:RealEstateInvestmentPropertyAtCost I {head="Real Estate, at cost"} I

Real Estate, at cost: Buildings and building improvements $3,107,234 $1,608, 1^5

Land and land estates 625,717 259,682

Land improvements 2, 044 2, 044

Fixtures and equipment 12,161 13,214

3,747,156 1,883,115 Less: accumulated depreciation 276,129 241,188

3 , 471 , 02 7 1 , 641 , 92 T

{all=^M "} token

The All token is only used in the string part of the pattern (2nd part) to specify a complex mapping pattern, such as:

DesiredTagName I { all="A previous heading : " "Next heading : " * "Deferred income " * } Deferred income

This means:

• Find a Stub label with the text string "Deferred income": preceded by

• A heading or stub that contains the text string "A previous heading:"; then

• Another heading or stub that contains the text string "Next heading:"; then • Any headings or stubs; then

• A heading or stub that contains the text string "Deferred income". {prevstub=" "} token

The Previous Stub token is only used in the string part of the pattern (2nd part), such as: I TheStubLabelAfterPreviousStub l {prevstub=" The previous stub" }A stub label I This means:

• Find a Stub label with the text string "A stub label"; preceded by

• A previous Stub label with the text string "The previous stub".

TheStubLabelAfterPreviousStubForStublessTotalRow | { head="The previous stub : " }

This means:

• Find a "stub-less" row; preceded by

• A previous Stub label with the text string "The previous stub".

{total} token

The Total token is only used in the string part of the pattern (2nd part), and is usually used to describe a "stub-less" data row with figures preceded by leading currency symbols:

TheTotalStubLabelAfterPreviousStub l { head="The previous heading : " } { total } I

This means:

• Find a "stub-less" Stub label with leading currency symbols (e.g., $); preceded by

• A previous heading with the text string "The previous heading:". Wildcards for Patterns

The following "Wildcards" are permitted in one or the other part of the tagname/string pattern list in the four list files. These wildcards will help associate stub data that varies with XML tagnames.

<*> Anything or Nothing Wildcard The Anything or Nothing wildcard will find any data or no data.

<+> Addition and <=> Sum Wildcard

The Addition and Sum wildcards are used in the tagname part of the pattern to create multiple tags in the output file. For example, the following pattern is used to create many XML tags in the output for specific stub data that contains "...less...$1,234 (2007)...": Account sReceivableTradeNet<+>AllowanceDoubtfulAccount s <=>AccountsR eceivableTradeGross I Accounts receivable<*>less allowances of <amount> (<year> )

1. The "AccountsReceivableTradeNet" to the left of the <+> sign, means: use that name for the data points found in the figure columns;

2. The "AllowanceDoubtfulAccounts" to the right of the <+> sign, means: use that name for the data points found in the language of the stub text (such as $1,234). 3. The "AccountsReceivableTradeGross" after the

<=> sign, means: use that name for the addition of the data points in the figure columns, plus the data points in the language of the stub text. <amount> Wildcard The Amount wildcard will find figures that are currency in nature.

<date> Wildcard

The Date wildcard will find either a single or double digit figure, optionally followed by "th", "st", "rd", or "nd", optionally followed by a comma.

<month> Wildcard The Month wildcard finds one single month either: all caps, initial caps or lower letters in English, French, Spanish and German and generally accepted abbreviations in English, French and Spanish:

English French Spanish

Jan / Jan. Jan / Jan. / Janv / Ene / Ene.

Feb / Feb. Janv. Feb / Feb.

Mar / Mar. Fe v / Fe v. / Fevr / Mar / Mar.

Abril Fevr. Abr / Abr.

May Mars Mayo

Jun / Jun. Avr / Avr. Jun / Jun.

JuI / JuI. Mai JuI / JuI. Aug / Aug. Juin Ago / Ago.

Sep / Sep. / Sept / Juil / Juil. Sep / Sep. / Sept /

Sept. Aoϋt / Aoϋt. Sept.

Oct / Oct. Sep / Sep. / Sept / Oct / Oct.

Nov / Nov. Sept. Nov / Nov.

Dec / Dec . Oct / Oct. Die / Die .

Nov / Nov. Dec / Dec.

This wildcard should be followed by other text to avoid improper replacements, such as "MAYFLOWER" to "MayFLOWER". To help avoid any improper replacement, this wildcard cannot be the last item in the search string or an error message will be displayed (see FIG. 18). Order of Patterns

The order of tagname/string patterns is important - where necessary, work from more inclusive to less inclusive, such as: namespace : EarningsPerShareDiluted I { head="NET INCOME PER SHARE : " } Diluted | | namespace : EarningsPer ShareDiluted | Diluted earnings I namespace : EarningsPerShareDiluted | Diluted Another example of correct pattern order:

RealEstatelnvestmentPropertyNet I { head="Real Estate , at cost " } {prevstub="Less : accumulated depreciation" } | us-gaap : RealEstateInvestmentPropertyAtCost I { head="Real Estate , at cost" } I

XBRLMark program-assisted tagging and mapping

As described above, when XBRLMark processes data, it identifies the relevant Financial Statements and other sections of the job to be processed, and then extracts and tags the pertinent data.

When the software extracts each table, and each data row in each table, it looks through the 4 pre-existing mapping lists: the active "Job List^"'; the client- specific "Client List"; the template- specific "Base List"; and lastly the "Taxonomy List". Typically an expert user will have "pre-engineered" the mappings, based on feedback from a client, and previous filings. XBRLMark looks through each of the four lists (which typically contain pre-engineered mappings for a particular client), and if it finds a match uses that match to process the data points in that data row. But if the software does not find a match, it will use its own internal logic

(described below) to build the tag name and to construct a mapping pattern "on-the-fly," ready for the XBRL/template user to make whatever adjustments are necessary to get the correct tag name if the newly created one is not sufficient. Building the tag name based on a Stub label In an embodiment, the internal logic to build a tag name uses the Stub label, if one exists (e.g., if it is not a stub-less total row).

In a straight-forward example, assume the Stub label is "Another new stub label". The most basic processing is to convert this string into Initial Caps, and remove the spacebands - e.g., "Another new stub label" would be rendered a new tag name of "AnotherNewStubLabel", which would be used to construct the Elements in the XBRL Instance.

And to accompany that new tag name an appropriate "mapping statement" would be created:

AnotherNewStubLabel I Another new stub label | As described, that is tag and mapping creation at its most basic. However, there are other steps and pieces of logic applied by the software, depending on the context of the data row.

Including Heading data in automated tag name and mapping There are certain conditions that will cause the software to include Heading information in a programmatically generated tag name and mapping statement.

If one of these conditions is met, then the software will look back for a previous heading or sub-heading, and if one is found, that heading (or sub-heading) will be included. These conditions include:

(a) If a "stub-less" total row is found (e.g., one that does not have stub text, but which has figure cells (e.g., "1,234")), then: a. The Tag name will be built of the word "Total" followed by the previously found heading or sub-heading e.g. "TotalHeading". b. The associated mapping will be built to include those items with "tokens", including both the { head"..." } and { total } tokens - e.g., | TotalHeading | { head="Heading" } { total } |

(b) If in a Balance Sheets financial statement, a "stub-less" total row is found (e.g., one that does not have stub text, but which has figure cells - AND it has a leading currency symbol (e.g. "$1,234") - AND it is preceded by a heading containing "Liabilities" or "Assets" - then: a. The Tag name will be built of the word "Total" followed by the previously found heading or sub-heading (e.g.,

"TotalLiabilities" or "TotalAssets"). b. The associated mapping will be built to include those items with "tokens", including both the { head"..." } and { total } tokens - e.g., I TotalLiabilities | {head="...Liabilities..." } {total} | or

I TotalAssets I {head="...Assets..." } {total} |

(c) If the user or template manager had entered "keywords" in the boilerplate entry # 50005 list - and if those strings had been found as a "stub label", and no pre-engineered mapping could be found - then: a. The Tag name will be built of the string found in the

50005 list, and the software will append the previously found heading or sub-heading in the Tag name; and b. The associated mapping will be built to include the { head="..." } token in the search pattern - e.g., I DilutedHeadmg | { head="Headmg" } Diluted | (d) If a stub label and data row, contained decimal figures in the data points - AND the previous sub-heading contained the keywords "per" and "share" or "unit" - then: a. The Tag name will be consist of the main stub label - plus the heading data - e.g., "StubLabelTheHeading"; and b. The associated mapping will be built to include the { head="..." } token in the search pattern - e.g,

I StubLabelTheHeading I { head="The heading" } Stub label (e) If there are duplicate stub labels in a financial statement -

AND the program is about to create one of those duplicates (i.e. it is not one that is previously mapped) - then: a. The Tag name will be consist of the main stub label - plus

- the heading data e.g. "StubLabelTheHeading"; and b. The associated mapping will be built to include the

{ head="..." } token in the search pattern e.g. I StubLabelTheHeading | { head= "The heading" } Stub label

(f) If the program is about to create a new tag name and mapping - AND a previously mapped data row (i.e. could have been matched from a pre-engineered mapping) already has the same tag name, and would result in a duplicate - then: a. The Tag name will be consist of the main stub label - plus

- the heading data e.g. "StubLabelTheHeading"; and b. The associated mapping will be built to include the { head= "... " } token in the search pattern e.g.

I StubLabelTheHeading I { head= "The heading" } Stub label The formats described with respect to the above embodiments are intended to be exemplary only. Those skilled in the art will recognize that other formats could be used with the present invention without departing from the scope of the invention. Embodiments of the present invention comprise computer components and computer-implemented steps that will be apparent to those skilled in the art. For example, calculations and communications can be performed electronically. An exemplary system is depicted in FIG. 19. As shown, computers 1900 communicate via network 1910 with a central server 1930. A plurality of sources of data 1960, 1970 relating to, for example, compliance data, also communicate via network 1910 with a central server 1930, processor 1950, and/or other component to calculate and transmit, for example, XBRL information. The server 1930 may be coupled to one or more storage devices 1940, one or more processors 1950, and software 1960. Other components and combinations of components may also be used to support processing data or other calculations described herein as will be evident to those skilled in the art. Server 1930 may facilitate communication of data from a storage device 1940 to and from processor 1950, and communications to computers 1900. Processor 1950 may optionally include local or networked storage (not shown) which may be used to store information. Software 1960 can be installed locally at a computer 1900, processor 1950 and/or centrally supported for facilitating calculations and applications.

For ease of exposition, not every step or element of the present invention is explicitly described herein as part of a computer system and/or software, but those skilled in the art will recognize that each step or element may have (and typically will have) a corresponding computer system or software component. Such computer system and/or software components are therefore enabled by describing their corresponding steps or elements (that is, their functionality), and are within the scope of the present invention.

Moreover, where a computer system is described or claimed as having a processor for performing a particular function, it will be understood by those skilled in the art that such usage should not be interpreted to exclude systems where a single processor, for example, performs some or all of the tasks delegated to the various processors. That is, any combination of, or all of, the processors specified in the description and/or claims could be the same processor. AU such combinations are within the scope of the invention. The present invention has been described by way of example only, and the invention is not limited to the specific aspects and embodiments described herein. As will be recognized by those skilled in the art, improvements and modifications may be made to the invention and the illustrative embodiments described herein without departing from the scope or spirit of the invention.

Claims

CLAIMSWhat is claimed is:

1. A computer-implemented method comprising: electronically receiving a document comprising securities compliance data; and electronically tagging with a computer processor terms in said document with XBRL tags; wherein said tagging comprises applying mapping lists, and wherein said mapping lists comprise a job list, a client list, a base list, and a taxonomy list.

2. A method as in claim 1, wherein said mapping lists are applied in a hierarchical order.

3. A method as in claim 2, wherein said hierarchical order is (1) job list; (2) client list; (3) base list: and (4) taxonomy list.

4. A method as in claim 1, further comprising building a tag name automatically if no match is found in said mapping lists.

5. A method as in claim 1, wherein said mapping lists comprise mapping statements.

6. A method as in claim 5, wherein said mapping statements each comprise a tag name and a matching pattern.

7. A method as in claim 5, wherein said mapping statements are grouped according to financial statement.

8. A method as in claim 7, wherein applying said mapping lists comprises identifying a financial statement and searching mapping statements grouped assigned to said identified financial statement.

9. A method as in claim 1, further comprising building an element tag based on an associated tag name.

10. A method as in claim 4, wherein building said tag name automatically comprises application of mapping tokens.

11. A method as in claim 4, wherein building said tag name automatically comprises application of wildcard variables.

12. A computer system comprising: a processor that electronically receives data describing a document comprising securities compliance data; and a processor that electronically tags terms in said document with XBRL tags: wherein said tagging comprises applying mapping lists, wherein said mapping lists comprise a job list, a client list, a base list, and a taxonomy list, and wherein said processor that receives data and said processor that tags may be the same or different processors.

13. A system as in claim 12, wherein said mapping lists are applied in a hierarchical order.

14. A system as in claim 13, wherein said hierarchical order is (1) job list; (2) client list; (3) base list; and (4) taxonomy list.

15. A system as in claim 12, further comprising a processor that builds a tag name automatically if no match is found in said mapping lists.

16. A system as in claim 12, wherein said mapping lists comprise mapping statements.

17. A system as in claim 16, wherein said mapping statements each comprise a tag name and a matching pattern.

18. A system as in claim 16, wherein said mapping statements are grouped according to financial statement.

19. A system as in claim 18, wherein applying said mapping lists comprises identifying a financial statement and searching mapping statements grouped assigned to said identified financial statement.

20. A system as in claim 12, further comprising a processor that builds an element tag based on an associated tag name.

21. A system as in claim 15, wherein building said tag name automatically comprises application of mapping tokens.

22. A system as in claim 15, wherein building said tag name automatically comprises application of wildcard variables.

23. An apparatus comprising: software, stored in a computer readable medium, that electronically receives a document comprising securities compliance data; and software, stored in a computer readable medium, that electronically tags terms in said document with XBRL tags; wherein said tagging comprises applying mapping lists, and wherein said mapping lists comprise a job list, a client list, a base list, and a taxonomy list.

24. An apparatus as in claim 23, wherein said mapping lists are applied in a hierarchical order.

25. An apparatus as in claim 24, wherein said hierarchical order is (1) job list; (2) client list; (3) base list; and (4) taxonomy list.

26. An apparatus as in claim 23, further comprising software, stored in a computer readable medium, that builds a tag name automatically if no match is found in said mapping lists.

27. An apparatus as in claim 23, wherein said mapping lists comprise mapping statements.

28. An apparatus as in claim 27, wherein said mapping statements each comprise a tag name and a matching pattern.

29. An apparatus as in claim 27, wherein said mapping statements are grouped according to financial statement.

30. An apparatus as in claim 29, wherein applying said mapping lists comprises identifying a financial statement and searching mapping statements grouped assigned to said identified financial statement.

31. An apparatus as in claim 23, further comprising software, stored in a computer readable medium, that builds an element tag based on an associated tag name.

32. An apparatus as in claim 26, wherein building said tag name automatically comprises application of mapping tokens.

33. An apparatus as in claim 26, wherein building said tag name automatically comprises application of wildcard variables.