For many businesses filing their financial statements using XBRL to comply with the SEC mandate, the phrase “extension taxonomy” is a largely misunderstood term.  There is a narrow view that it is only about adding brand-new company-specific elements which do not exist in the base taxonomy (Ex: US GAAP 2009). While adding new elements is definitely one of the purposes for creating extensions, there are many other drivers for creating an extension taxonomy. Even though some of the principles apply for other scenarios, this blog post specifically refers to extension taxonomies as they are used to meet the SEC XBRL mandate for operating companies.

The reality is that almost all of the XBRL filers to date have created a barebones extension taxonomy. Because you’ll be delivering your own unique extension taxonomy to the SEC – and a slightly modified version of the taxonomy with every quarterly and annual financial statement you certify – it’s important to understand the component parts of the document, and some basic rules to help guide you in developing it.

An extension taxonomy is not just about a new set of tags (or elements). Elements are actually very specific pieces of information, and the XBRL US GAAP Taxonomy Preparer’s Guide advises preparers to first determine if it is possible to use more general – and less specific – extension tactics.These higher-level tactics can be re-used in future periods, resulting in much less effort over time.

You can tackle creating an extension taxonomy by thinking about it as an upside-down pyramid: begin with the most general set of extension tactics, and see if that suits your purposes. If not, move to a lower level, where more specific information is required. For the purposes of this blog post, we’ve grouped the twelve methods of extending the taxonomy under four, easily remembered headings, listed mostly by the increasing levels of impact that the tactic will have upon future re-usability.

1. Relationships Help Present Your View

It is recommended that companies perform the following at a minimum: (1) create new Relationship Groups, and (2) change the Ordering of existing relationships defined in one of the Industry Entry Points. These methods of extending the XBRL US GAAP Taxonomy have the most capacity for future re-use.

A new Relationship Group allows preparers to assemble custom presentation relationships between already existing elements, tables or existing groups.

Changing the Order is as simple as reordering the children in an existing list.

In some cases, simply modifying relationships within one of the existing Industry Entry Point taxonomies can be sufficient for a business to complete their own extension taxonomy. For example, you might need to modify the order of a list as follows:

It is also possible to (3) add New Relationships between existing elements. An example would be creating a new calculation for multiple elements.

Preparers can also (4) suppress or change a Parent-Child Relationship; however, this is typically done only to resolve a validation error or calculation inconsistency.

Adding New Relationships or suppressing Parent-Child Relationships both have slightly more impact on future re-use of the extension taxonomy, and should be investigated only after determining if the labeling methodologies below can first do the job.

2. The Role of Labels

The SEC recently presented its findings from a review of the Year 1 XBRL filings recommending that an “element label should match its line item caption”. It is recommended, especially for any kind of tabular data, to modify the labels on elements (especially tabular information) to match your financials.

There are three ways labels could play a part in your extension taxonomy: change the Preferred Label on a Presentation Relationship, add a new Abstract Heading Element, or simply add or change Element Labels.

• Changing a Presentation Relationship’s Preferred Label helps dictate how data is displayed. An example would be to change the preferred label on a line item’s presentation relationship from “Terse” to “Negating”, ensuring that the numerical data displayed for that line item has its sign flipped.
• Adding a new Abstract Heading Element simply provides a new heading, under which child items can be grouped. Preparers should first determine if they can modify the label of an existing abstract element prior to creating a new one.
• Adding or changing Element Labels does not modify the element’s definition or references, both of which are the crucial pieces of data used to define that element. This is always preferable to creating a new element, which is described below under the section on elements, and has less future potential for reusability.

Of all labeling methodologies, the Preferred Label on a Presentation Relationship concept is the most difficult for people to understand, and warrants further explanation. Every tag or element has several different types of display labels, each of which can be used in different places throughout your financial statement without modifying the underlying data.

Different parts of your financial statement can reference different label types using Preferred Labels, changing the information displayed on your financial statement without actually changing the tag itself, or the underlying data. In one section of your financials, you might want to change the preferred label for [Goodwill] to “Period End” in order to display “Goodwill, Ending Balance” on your financial statement.

3. Extensions and XBRL Tables

XBRL Tables are powerful constructs, allowing you to group, display and reformat data – all without changing the underlying relationships between the data included in the table itself. For the purposes of this blog post, we will assume that readers have a basic understanding of XBRL tables and terminology, which can be found in Chapter 5 of the XBRL US GAAP Taxonomy Preparer’s Guide.

There are three ways to extend using tables, add a new (8) Domain Member to an Existing Table Domain, add a new (9) Axis to an Existing Table, and add a (10) New Table.

• Adding Domain Members is one of the most common ways of extending taxonomies, especially as you get into detailed tagging. As an example, the Domain “Major Types of Debt and Equity Securities” might be composed of the following Domain Member Elements: “U.S. Treasury Notes”, “Corporate Debt Securities” and “Equity Securities”. Adding a new Domain Member Element to an existing Domain essentially adds a new table column, into which you can add financial data.
• A table Axis contains one or several Domains. Adding an Axis to a table allows you to group Domains together for more complicated reporting requirements. Imagine that you are reporting “Assets by Type” (your Axis) and need to also break them out by “Assets by Location” (your new Axis). Adding the new location Axis would allow you to create a master column by asset type, under which assets by location could be individually reported.
• Before adding a New Table, first determine if you can modify one of the tables available in the existing XBRL US GAAP Taxonomy Industry Entry Points, either by adding Domain Members or Axes as described above. Adding a new table is more difficult than modifying an existing one – requiring that you modify, create or define additional elements, attributes, and relationships. But in some situations it will be necessary.

The example below illustrates how adding a new Axis can help you group data for more detailed reporting situations than the standard taxonomy might allow. In this scenario, the Axis “Reporting Segment” was added to the original table, facilitating this grouping:

4. Add New Elements Only When Required

So far, so good. We’ve made it through nine of twelve methods to extend the existing taxonomy to suit your unique business situation – all without creating new elements or tags. But in some cases, you’ll need to do just that. As we’ve already said, creating new elements or tags has the most impact on future re-use, so do your best to repurpose what already exists prior to extending using the methods below. This is one of the areas which has the highest impact on comparability of data across companies – and will be one which regulators will watch very closely.

Adding new elements should only be done once the existing taxonomy has been completely reviewed, including documentation on existing elements, to determine if one of the methods above can first suffice. If not, there are two ways to add a new element: adding a new (11) Numeric Element, or adding a new (12) String,Text Block or Other Non-Numeric Element. The scope of this post is not sufficient to cover the ins-and-outs of creating new elements, the details of which can be found in Chapter 6 of the XBRL US GAAP Taxonomy Preparer’s Guide.

There are some good rules of thumb to follow:

• You will usually need to add a new Numeric Element in two situations: if you need to combine two or more line items into a single element or if you need to introduce entirely new financial reporting concepts which are not covered in the existing taxonomy. Every new Numeric Element requires both a definition, and a presentation relationship to at least one other element. When you are adding new elements it is very important that you take the time to document the purpose and reasoning behind the same. It’s usually a good idea to go ahead and develop at least one calculation relationship to one or more other elements for all Numeric Elements you create.
• Adding a Non-Numeric Element (such as a text block or string) is performed when the existing tags don’t meet your needs, especially for block tagging of complete notes, individual accounting policies or tables/schedules. Non-Numeric elements do not participate in calculation relationships and you cannot validate content inside it using traditional calculation relationships.

Conclusion

Extension taxonomy documents are as important as the Instance documents you submit to the SEC. Special attention must be paid to the contents of the extension taxonomy. Extension taxonomies are much more than just about adding new elements; they include changes to Relationships, Labels, XBRL Tables, and more. Even if you have completely outsourced your XBRL preparation, it’s important to work with your outsourced provider to understand what goes into your extension taxonomy since it is one of the documents that you will be filing with the SEC.

Many reporting managers feel comfortable with the basics, but are often worried about missing some nuance. Looking at the actual rule, it seems relatively straightforward in scope. Here are the basics:

• The requirement will apply beginning with a “periodic report” on Form 10-Q, Form 20-F or Form 40-F containing financial statements for a fiscal period ending on or after June 15, 2009 and will be phased in as follows:
  • LAF using US GAAP with public float >$5 Billion:
    • June 15, 2009 – Face Financials and Block Tag Notes
    • June 15, 2010 – Face Financials and Detail Tag Notes
  • All other LAF using US GAAP:
    • June 15, 2010 – Face Financials and Block Tag Notes
    • June 15, 2011 – Face Financials and Detail Tag Notes
  • All other filers using US GAAP:
    • June 15, 2011 – Face Financials and Block Tag Notes
    • June 15, 2012 – Face Financials and Detail Tag Notes
  • Foreign issuers using IFRS/IASB:
    • June 15, 2011 – Face Financials and Block Tag Notes
    • June 15, 2012 – Face Financials and Detail Tag Notes
• The interactive data is to be filed at the same time as the filings to which is relates.
  • However; the rule allows the first block tagged and first detailed tagged XBRL exhibits a grace period of 30 days.
• Financial statements in XBRL format must be posted on the corporate website no later than the end of the calendar day it filed or was required to file.
• Interactive data files are excluded from officer certification requirements. Auditors are not required to audit the interactive data files.
• The interactive data files will be subject to modified liability as long a filers “make a good faith attempt to comply with tagging requirements.”
• The SEC has a test filing process to help companies catch errors before actual submissions.

As we all know, most SEC guidelines just aren’t that cut and dried. Many of my customers have specific questions: What if the company changes filer status? Will the previewer have validations? What are the penalties for late or erroneous XBRL filings? The answers to my questions could all be found in the final rule itself. But I wanted confirmation that a loophole, caveat, or some barely-legible fine print didn’t make my conclusions obsolete.

So I decided to give the SEC’s newly promised accessibility a test drive, and picked up the phone the other day to determine how easy it might be for inquiring minds to get these questions answered. In past lives, I’ve only talked to the SEC directly in my capacity as an auditor of SEC comment letters. Let’s just say that these weren’t always pleasant conversations.

To my surprise and pleasure, I received a very prompt response (within a few hours) from an SEC expert, who requested a teleconference with me to answer my questions. The SEC analyst I spoke with was actually involved in drafting the rule. He patiently answered my questions, confirming my understanding of the written rule in laymen’s terms. He said things like “let’s step back for a minute” and “let’s use that example” and walked me through scenarios in a helpful and instructional way.

The next time you have a question on XBRL, I’d recommend that you go straight to the source: pick up the phone and call the SEC directly. The help desk appears to be open.

You can email the SEC directly with questions about the final interactive data rule here: Ask-OID@SEC.GOV

Things To Look For In An ACH Solution

• Trending
  • Historical deposit data should allow you to forecast future activity based upon business rules.
• Anticipatory Calculations
  • Your ACH process should support configurable, anticipatory ACH calculations based upon past trends. Look for a solution which allows you to factor in bank or other holidays, historical Point-of-Sale data, and other factors. The goal should be to maximize balances in your interest-bearing accounts by transferring money before you know for certain how much has been dropped into your depository accounts.
• Risk Thresholds
  • Any solution should include thresholds for risk – the higher your threshold, the more money you will transfer (and the more interest you will earn on those funds). The lower your threshold, the fewer overdrafts you’ll incur from aggressive calculations.

The ACH sweep is a targeted process which can be dramatically improved, using a combination of automation and the targeted application of business rules. Done right, a more streamlined ACH calculation and sweeping methodology can save your business time, money, and effort … maximizing profit margins and allowing you to focus on more strategic priorities in the Office of Finance.

Automation is the critical lifeblood of an effective account reconciliation process. But software can’t solve everything – just as important is the continuous controls improvement process surrounding the software. At Trintech, we’ve identified seven best practices to help our customers ensure an effective, factual, and high quality account reconciliation process. Some of the key elements of each practice are highlighted below.

• 1: Account Assignment
  • Administration must be performed efficiently, either in a decentralized or Centralized environment
  • New accounts are identified automatically ensuring 100% coverage of the GL
  • Ideally Business Units should be empowered, with central visibility and control
• 2: Procedural Documentation
  • Complete account descriptions exist, with supporting controls, policies and rules
  • Document repository contains account and reconciliation history, including attachments
  • Approval and change management workflow is documented
• 3: Timely Reconciliation and Substantiation
  • Live, role-based dashboards track progress in real-time
  • Automated support for account grouping, interactive matching, high-volume transaction matching and search/filter criteria
  • Bulk reconciliation tools support zero balance, no activity, threshold, and Dynamic Risk Ratings
• 4: Issue Isolation
  • Past dues are highlighted automatically, with triggered notifications to users and managers
  • Audit trail captures all commentary and notes
  • High risk accounts are flagged for continuous monitoring
• 5: Issue Escalation and Resolution
  • An automated and collaborative escalation workflow exists
  • Configurable reporting features capture all facts
  • Item aging and carry-forward rules exist, enabling lock-down on completed work
• 6: Adjust with Integrity
  • A highly controlled adjustment workflow exists: including creation, review, and approval
  • Reconciliations are re-performed when balances change
  • Controlled closure of open items
• 7: Empowered Personnel
  • Standardized reconciliation templates, with built-in account certification and confirmation
  • Easily accessible reference information to ensure high-quality reconciliations
  • Continuous and inclusive audit trail

Strategic companies won’t view SOX compliance as just another box to be checked off. They will instead approach the account reconciliation process with a best-practices mixture of tools, processes, and attitude that ensures not only compliance, but savings in hours, effort, and fees … all of which translates directly to the bottom line.

Over the next few weeks, we will take a look at each of the 7 elements above and focus closer in to highlight areas of efficiency, automation and ultimately 20/20 transparency and accountability.

In most companies the financial reporting process remains largely manual: document roll-forward, gathering input from around the globe, assembling packets of redlines, data input – all are largely managed with tools such as Microsoft Word, e-mail, the telephone – and a significant amount of nagging. In the center of this process is the SEC reporting manager, who acts as a human hub: administering process, reviewing changes, brokering conversations with critical board and management members, and facilitating relationships with the printers and auditors.

In the last six years, financial reporting has been under significant pressure. Sarbanes-Oxley increased the requirements for certifications and controls, deadlines for reporting were shortened, and XBRL created another step in the filing and preparation of financials. Globalization compressed already tight deadlines, and requires additional collaboration. The IFRS and SEC plans to overhaul the reporting systems promise changes down the road. Given the economy, making the business case for additional staffing will be difficult.

Time For Relief

It’s time to relieve the SEC department of manual risk and administrivia. The current model isn’t sustainable: managing a global and manual process, in an environment where the rules are shifting, and the technology requirements increasing, while staff levels are falling. It’s a recipe for disaster, one reason why some companies have jumped at the chance to transform the process with automation.

There truly are options to move the process to a less manual place. Here are some suggestions to consider when automating financial reporting:

• 1: Create an Agile Process
  • Create a reporting process that can adapt to future scenarios, can sustain turnover, and support a global operation.
• 2: Be a Change Agent
  • If you are at the end of a manual close process, start using tools that support collaboration in data gathering, allow visibility into the status of the document drafts, and decrease the administration for your staff. Set an example: what’s possible? How can you innovate? Facilitate meaningful discussion about process optimization, and hold regularly-scheduled meetings to review progress.
• 3: Build and Maintain Momentum
  • Rome wasn’t build in a day. Similarly, changing an important process such as financial reporting will depend on incremental, gradual improvements over time. Wean team members from the old ways. Allow paper-based reviews for some period of time. Move process-by-process onto technology, and trumpet your successes as they occur.

Automation of the financial reporting process has clear benefits: increased transparency, reduced costs and effort, shorter cycle times, better information with which to make strategic business decisions. If you decide to move from a manual environment to an automated one, become knowledgeable about the technologies available to support the reporting process, and build with the future in mind. So when new requirement arrive in your in-box, you’ll be poised to act.

PCI-DSS is comprised of 12 discrete requirements, dictating how card processors handle everything from network security standards to data encryption:

• 1. Install and maintain a firewall configuration to protect cardholder data
• 2. Do not use vendor-supplied defaults for system passwords and other security parameters
• 3. Protect stored cardholder data
• 4. Encrypt transmission of cardholder data across open, public networks
• 5. Use and regularly update anti-virus software on all systems commonly affected by malware
• 6. Develop and maintain secure systems and applications
• 7. Restrict access to cardholder data by business need-to-know
• 8. Assign a unique ID to each person with computer access
• 9. Restrict physical access to cardholder data
• 10. Track and monitor all access to network resources and cardholder data
• 11. Regularly test security systems and processes
• 12. Maintain a policy that addresses information security

Compliance is assessed each year by card issuers and acquirers (think Visa, Mastercard, AMEX), with organizations who process large volumes of credit card transactions (more than 6 million transactions in any given year) subject to an annual on-site audit and quarterly network scans by an approved Qualified Security Assessor. Smaller businesses can self-certify via a Self-Assessment Questionnaire.

Penalties for non-compliance can be stiff, with fines of up to $500,000 and the financial and legal headache resulting from audits, legal action from leaked data – not to mention the embarrassing public relations issue which can arise if cardholder data is breached. Businesses who continue to fail compliance tests can lose their ability to process credit card transactions altogether.

What To Look For In A PCI-DSS Compliance Solution

A flexible compliance solution will be key to successful PCI-DSS compliance. If you’re already using a compliance tool for SOX, first examine whether or not it can be configured to manage PCI-DSS compliance efforts as well. Standalone PCI-DSS solutions will be rare. It’s interesting to note that PCI-DSS is enforced separately by issuing organizations – so even though the standard exists to streamline your compliance efforts, each organization may require slightly different sets of documentation. Your solution should include the ability to upload published PCI-DSS control libraries, allowing you to record any nuances by card issuer, and offer electronic delivery of all required documentation with the click of a button.

PCI-DSS, like so many other regulations, is here to stay. Strategic businesses will integrate compliance with the standard into a culture of compliance and, like SOX compliance, learn to leverage these discrete compliance checks within a broader process improvement initiative … helping them do things faster, better and smarter in the Office of Finance.

If a customer purchase an iPod, and forgets to buy a pair of headphones, a retailer might send an email with a bundled offer featuring earbud headphones and another, less popular item. The customer, who we know from analyzing aggregate customer behavior probably wants those headphones, will be incented to return to the store, buy the headphones … and an incremental accessory as well. Now the store has leveraged the customer’s affinity for one thing, tied it to a less desirable thing, and increased revenue all at once.

Finance Can Learn From Database Marketers

The secret to database marketing is Key Performance Indicators (KPIs), and how they’re tracked over time. KPIs are rates, ratios or percentages that help a business optimize some process or discrete function. Never expressed as raw numbers, which tend to confuse consumers of the data, KPIs can be a powerful ally for the Office of Finance in streamlining productivity and processes – especially in the dreaded Financial Close and Financial Reporting process.

Rules of Thumb for KPIs and the Office of Finance:

• 1: Less is More: Once you understand the power of KPIs, you’ll be tempted to go KPI-crazy. Don’t. Any more than 5 or 6 KPIs and you’ll be overwhelmed.
  • Example: You might track only a few KPIs about the Financial Close, including metrics like:
    • Increase / Decrease in Labor Cost per Close Period =
      [ (Total-Man-Hours-Period-1 x Hourl- Labor-Rate) - (Total-Man-Hours-Period-2 x Hourly-Labor-Rate) ]
    • Rate Of Incremental Effort Required To Close =
      [ Total-Man-Hours-In-Close-Period / (Man-Hours-Per-Average-Workday * Number-Of-Days-In-Period * Number-FTEs-Involved-In-The-Close) ]
• 2: Establish Benchmarks and Thresholds for Performance: It’s important to establish baseline benchmarks with an initial read on how things are going, and then set thresholds for performance over time.
  • In the example given above, you might initially determine that your team is working 4 hours per day more than usual during the financial close, as follows:
    • Total-Man-Hours-In-Close-Period = 180 hours (it took 180 total man hours to complete this close)
    • Man-Hours-Per-Average-Work-Day = 8 hours (assume a full work day of 8 hours)
    • Number-Of-Days-In-Period = 5 days (it took you one business week to close the books)
    • Number-FTEs-Involved-In-The-Close = 3 employees (each working full-time closing the books)
    • Rate Of Incremental Effort Required To Close = [ 180 / (8 * 5 * 3 ) ] = 1.5
  • In this scenario, 1.5 is your baseline measurement. Obviously a rate of 1.0 would be desirable to everyone: the close can be accomplished without anyone working overtime. And anything over 1.6 or 1.7 might mean that you begin to lose employees or see an increased number of task re-work due to fatigue or error.
• 3: Determine Next Steps: Now that you’ve set thresholds for performance, you should know in advance how your business will respond if a KPI does not perform up to snuff. A KPI is useless unless you’re using it to optimize your business and gain competitive advantage by doing things faster, better, or smarter.
  • Let’s take the Rate of Incremental Effort KPI above. A goal of 1.0 might be unrealistic to achieve, so your team decides to set a target of 1.2 and work to optimize processes with automation in order to achieve that target. But what happens if your rates go up? What if you’re seeing a rate of 1.7 or 1.8, consistently? Have a plan to hire more resources, install software, or re-engineer processes to bring the rate down to your target goal.

Financial professionals should think about stealing a page from the playbook of database marketers when trying to transform internal business processes. With the advent of advanced technologies like XBRL, and modular, automated workflow management solutions like Trintech’s Unity Financial GRC Software Suite, businesses are uniquely poised to reap the rewards from an effective data capture, analysis, and optimization effort in the Office of Finance.

Because many of the processes in the finance process are non-linear, it can be difficult to envision how technology can help. Visualizing an example process – such as bad debt reserve preparation – makes it easier to imagine the possibilities.

The following graphic describes a production platform for finance as described below. For reference, an optimized Bad Debt Reserve Analysis is imagined below the illustration.

Click the preview image below for a larger version.

Example Bad Debt Reserve Analysis, Optimized upon an Automated Finance Production Platform:

Transaction Created

• Customer buys product online
• ERP creates receivable and revenue
• Account owner notified by ERP of “out of tolerance” conditions
  • Action plan sent to owner, and adjustment or correction made, while all support recorded in system of record
• Bad debt reserve recorded by ERP
• Accounts receivable ledger closed by ERP for period

Accounting Judgment Applied

• ERP and BI tools deliver bad debt reserve analytic
  • ERP and BI tools combine operational and transactional data and create the accounts receivable bad debt information in the designed company format
• Automated scheduler sends bad debts reserve task to account owner on scheduled date
  • Appropriate accountant receives an email with link to desk procedure and all the related information including the pre-populated spreadsheet, rules, and a predefined work flow
• Automated due-date reminder sent to account owner
  • Due-date reminders sent, and late notices escalated to management
• Task reassignment “dragged and dropped” due to change in account ownership
  • Task changes due to vacation and changes in personnel are reassigned in bulk
  • Full audit trail created with changes
• Bad debt reserve analysis performed in process automation tool
  • Bad debt analysis performed and other third party knowledge added to final calculations
  • All support attached and recorded in system

Analysis Reviewed and Approved

• E-mail notice of completed bad debt reserve received and approved in work flow
  • All comments, consultations, and support recorded
  • All attachments moved through approval process
• ERP journal entry used to upload final adjustment
  • Any final adjustments recorded via direct interface with the ERP and all supporting documentation
• Internal audit reviews bad debt reserve via web-browser
  • All questions and schedules exchanged on the systems and recorded
• Online binder delivered to external auditor via web or CD

Final Numbers Reported

• Integrated reporting technology supports report creation
  • A financial reporting hub is used for the creation; roll forward, review and editing of financial statements
• XBRL process automated and embedded in reporting tools
  • XBRL process is embedded in financial reporting process
  • XBRL tagging and validation are part of the financial reporting hub
• “Push button” financial reports are created
  • All of the collected disclosures for a filing are compiled, including XBRL instance documents ready for filing with regulators

To understand the gaps in current finance technology, the record-to-report (R2R) process needs to be analyzed. From a production platform standpoint, R2R can be compartmentalized as follows: transaction processing, technical close, controller’s close, and financial reporting.

Every company invests in technology differently. The analysis below is intended to illustrate a broader truth: where technology currently supports the finance process … and where more automation is needed. For the purposes of this review, desktop automation tools are considered manual processes. This overview is based on observations across many companies, and reflects a macro-view of most major processes.

Transaction Processing:

Currently supported by technology:

• Streamlining basic processes and performing the bookkeeping to arrive at a trial balance
• Validation of clerical entries
• Force balancing debits and credits
• Security around transactions

More automation is needed:

• Intercompany account balancing and controls
• Manual journal entry tracking
• Tracking supporting documentation

Technical Close:

Currently supported by technology:

• Closing sub ledgers
• Consolidating the financial statements
• Delivering the financial statements to controller’s department
• Creating/delivering standardized reports

More automation is needed:

• Managing ERP “job” processing
• Creating/delivering customized inquiries/reports

Controller’s Close:

Currently supported by technology:

• Accessing data required for analysis
• Formatting analytics
• Viewing and reviewing first draft financial statements
• Producing key “flash” information

More automation is needed:

• Administering the global close schedule
• Getting consistent, timely data on collaborative charts (commitments, leases…)
• Obtaining detailed snapshots of progress
• Tracking and documenting key issues
• Managing final adjustments
• Managing account reconciliations
• Creating, documenting manual journal entries
• Managing the external audit process

Financial Reporting:

Currently supported by technology:

• Timely, accurate, and completed financial statements
• Outsourced/automated Edgarization of filings
• Attaching selected XBRL tags

More automation is needed:

• Roll-forward of financial statements
• Gathering and collating of notes to the financial statements
• Gathering and collation of appendices and MD&A
• Distribution and receipt of draft financial statements
• Editing “master” financial statements
• Determining and selecting XBRL tags
• Creating and storing support for final filed financial statements

Given the above, R2R moves initially from automated production activities to manual, offline efforts in two places: 1. In the subjective application of accounting judgment, and 2. In the administration and review of the process itself. The processes that require people to make decisions and interact with systems – such as reserve calculations, complex reconciliations, or footnote preparation – are often taken offline into manual and office automation tools, such as spreadsheets and e-mails. The administration and tracking of these processes, including supporting documentation, are often managed most effectively using office automation tools, or occasionally document management solutions.

Finance departments are beginning to use technology to fill gaps in their production processes. Examples of production environments in finance include:

• Job Monitoring: Technical close, managed in tools that monitor and report job processing issues, including proactive rescheduling to move processing times. Optimizes capacity and efficiency.
• Financial Close Scheduling: Close task list, fully automated to manage the scheduling and delivery of close tasks to the right person at the right time. Escalates and reminds with appropriate and timely templates.
• Financial Close Monitoring: Close, managed through interactive dashboards, giving status of all compliance, close and reporting details throughout the process.
• SOX Compliance: SOX compliance, managed with automation of required tasks, including: testing, reporting, and certifications.
• Account Reconciliations: Reconciliations performed, tracked and reviewed in a single platform with dashboard visibility.
• PCI Compliance: PCI compliance requirements scheduled, performed, tracked, and reported via automated workflows.
• Financial Reporting: Financial reporting processes supported by workflow, enabling collaborative drafting and management across internal and external constituencies.
• XBRL: XBRL requirements embedded in financial reporting processes, supporting in-house mapping, creation of extensions, tagging, and validation.

Technology solutions offer finance the opportunity to create agility in processes, absorbing externally-driven demands and supporting internally-driven growth. Finance has often relied on people to fill the gaps when technology was unavailable. But making the business case for dramatic increases in staff has been made more difficult by the recession. This much we know: further regulation and change are guaranteed; business is picking up; and the technology is available that can help companies close the automation loop – finally delivering a true production framework for the R2R process, and a strong foundation for success moving forward.

The SEC is allowing companies to ease into compliance, laying out a two-phase mandate. During the first year, only the face of the financials must be tagged with XBRL, necessitating anywhere from 300 to 500 discrete XBRL tags. But in year two, that number increases almost exponentially, requiring anywhere from 2,000 to 4,000 discrete tags, depending upon your unique business environment.

For businesses seeking to bring XBRL compliance in-house, there are essentially two types of solutions available: Bolt-On and Embedded. Each tool offers unique advantages.

• Bolt-On tools tend to snap in at the tail-end of a process. Especially during the less stringent year one of compliance, these tools could make sense for businesses with an appetite for the intricacies of XBRL. A Bolt-On solution comes into play only after the financial report has been prepared in Word/Excel/PDF format, allowing you to tag an almost finished financial report. But depending upon the capabilities of the solution there may be a need to re-tag many parts of your financial report in the subsequent – sometimes even the same – period.
• Embedded solutions, on the other hand, require a higher initial investment from the business. But as your organization moves into year two of compliance, these solutions begin to show a dramatic return on investment. Embedded solutions allow the embedding of XBRL capabilities deep into the financial close/reporting process so that tagging isn’t an afterthought but blends into the process steps of close/reporting. Hence all the capabilities which you use in producing your regular financial reports like workflow/collaboration/formatting/validation/notification are very much relevant for XBRL tagging as well. In addition embedded solutions allow you to tag content within your financial report once and re-use them every period. This provides the efficiency required to file efficiently when there are 4,000+ tags (especially in year 2) and also helps meet same-day filing deadlines.

When evaluating Bolt-On versus Embedded XBRL software solutions, financial professionals should look for specific functionality to ensure that the efforts in year two and beyond can be sustained internally by their team:

1. 1: Tag Roll-Forward
   • After the initial tag setup, can you re-use XBRL tags in financial reports for future periods with minimal effort?
   • Are the XBRL tags maintained against content within a Disclosure so that edits do not require re-tagging?
2. 2: Formatted View of Tagged Disclosures
   • Do formatting and tagging occur in the same application? E.G. – “What you tag is what you see?”
   • Is the user experience intuitive? Does the system hide the complexity of XBRL from the user, or require them to understand more than is required in order to successfully tag a disclosure?
3. 3: Single Data Repository
   • Are your regular and XBRL filings managed in the same system?
   • Do you have the ability to change content at just one place so that it automatically publishes both XBRL and regular financial reports ?
4. 4: Multiple User Tagging Workflow
   • Can multiple users tag and work on different parts of the document at the same time ?
5. 5: Multi-Jurisdictional XBRL Reporting
   • Can the system help manage the reporting requirements for multiple jurisdictions (SEC, HMRC, etc.)
   • Can the system manage multiple versions of the same taxonomy (2009, 2010, and extensions)? This is important as XBRL US and other organizations publish updates to the taxonomies.
6. 6: Enables Same Day Filing
   • Does the system allow for same-day filing by allowing single button publish of XBRL and regular financial reports ?
7. 7: Integration to Source Data
   • Can the solution import financial data directly from your ERP or other consolidation system?
8. 8: Context-Driven Tagging
   • Does the system present the right tagging levels at the right parts of the financial statement reporting/preparation process ? E.G. – Does your system know that certain tags relate to an “income statement”?
9. 9: Audit Trail
   • Who changed what, and when?
10. 10: Extensibility
    • Does the system enable the use of XBRL for internal reporting in the future?

XBRL compliance is a new, sometimes intimidating prospect for most companies. Many will choose the path of least resistance in year one, selecting inexpensive Bolt-On solutions in the hopes that compliance can be achieved easily. But if SOX has taught us anything, it’s that the most successful adoptions of XBRL will include a strategic focus, integrating the increased transparency offered by the language directly into business processes which begin prior to the generation of the financial report itself.