Preparing your financial statements (Form 10-Q, Form 10-K, Form 20-F) for the XBRL reporting required by the SEC is a two-step process: mapping comes first, followed by the actual XBRL tagging of the financial report itself.

• Mapping matches your financial statements to the US GAAP XBRL taxonomy.
• Tagging is the process of using the “plan” created in the mapping process, and actually applying the XBRL tags to your filing documents.

MAPPING YOUR FINANCIAL STATEMENTS TO THE US GAAP TAXONOMY:

Mapping can be performed within an embedded solution of your choice and can also be used to manage your XBRL tags and extensions moving forward. Mapping is largely performed once – once a business or financial fact is mapped to a taxonomy element, the mapping generally doesn’t change. It is very important that you have a good idea to have a working understanding of the XBRL US Implementation Guide.

To begin, first import the US GAAP XBRL taxonomy into your embedded solution. Using your XBRL financial reporting software, perform a mapping of your business’s individual disclosures and matching them to the XBRL tags contained within the US GAAP XBRL taxonomy.

The “Presentation” link in the Taxonomy is the best place to begin matching your disclosures to the US GAAP taxonomy. If you can’t easily find the Element you’re seeking, try doing a search in the taxonomy, using the “search” function in your solution.

Mapping should be a methodical process. areas An embedded solution will help you manage different disclosures such as the Balance Sheet, Income Statement, Cash Flow Statement, Statement of Changes in Stockholders Equity, and more as individual components.

• Mapping Best Practice:
  • Regardless of how you decide to approach the mapping process, it’s important that your Finance team is in control of the strategic decisions relating to your eventual selection of Elements and tags.
  • An outside provider might have a better understanding of taxonomy elements and there specific meanings, but it is very unlikely that they would possess the in depth knowledge your Finance team has about your financial amounts and how each was derived.

Though most mappings will persist from one period to another, minor edits may be required from time to time. For example, if a new line item is added to a financial statement, the new line item would need to be mapped to the appropriate taxonomy element. Other exceptions that might require modifying a mapping could include the issuance of a new US GAAP taxonomy, where an element previously used was deleted; or discovery of a mapping error that needs correction.

TAG YOUR FINANCIAL REPORT WITH XBRL:

Now that mapping is complete, it’s time to begin tagging your Form 10-Q, Form 10-K, or Form 20-F with XBRL. Tagging is performed in an XBRL tagging and output solution, such as Trintech’s Unity XFR financial reporting tool, an embedded XBRL solution which reduces ongoing maintenance effort and cost by persisting tags from one period to the next using “smart” reporting templates.

Refer to our earlier blog post here about the importance of the “Map >> Tag >> Validate” lifecycle. It’s essential to validate your mapping, extension taxonomy, and XBRL tagging efforts early and often – this will save you time and headache down the road.

While the details involved in actually tagging your financial report are too extensive to compile in this blog post, several best practices are beginning to materialize from the deluge of filings the SEC has seen to date.

• Context Is Important:
  • A particular tag may be re-used on the Income Statement for three separate years (giving it three separate contexts). In the case of Revenue, the actual revenue and the pro-forma revenue is presented for only one year. However, when you see in the SEC previewer the revenue information for all three years is displayed.
  • This is acceptable, and not considered an error, because if the same tag is used at different places then it will pick that tag for all the years presented even though in your actual disclosure it is presented for only one year.
• Labels Are Tricky:
  • If you’re using the same label and label type for multiple tags, validation errors might occur.
  • Pay attention to the details. If you’ve chosen a particular tag to represent shares item type rather than monetary item type, make sure you pick the correct tag. Picking
    StockIssuedDuringPeriodValueTreasuryStockReissued rather than StockIssuedDuringPeriodSharesTreasuryStockReissued could result in a report that incorrectly represents the monetary information as share type.
  • Sometimes a number may be showing as a positive value on the income statement, however in a disclosure note it may have been shown in parenthesis as a negative number. Check for the negated label sign.
• Level 4 XBRL Tagging Requires More Effort:
  • Apart from monetary and share information the information presented in percentages, share price, useful life in years etc should also be tagged.
  • Make sure if the information is presented as an instant or duration.
  • Where there is a range for eg exercise price of options range from $1-$5, the concept of minimum exercise price and maximum exercise price should be used to present the range.

After the tagging and validation work is done, the preparers should review the entire instance document using a solution like Unity XFR in addition to uploading the instance documents to the SEC previewer. At a first glance you may notice inconsistencies in the presentation. The SEC Reporting Manager should conduct a detailed tracing of every element, its label and presentation from the rendered statements to the source document (eg 10-K, 10-Q, 20-F). Be careful to validate that the labels created for each Element match the information presented on the financial report especially for the face financials and tabular data.

Ensure that the dimensional table accurately reflects the information you intended to display. Sometimes while designing the table you may have intended to present the table in a particular format, however the person performing the mapping may have misunderstood, and the dimensional table may not accurately reflect your intent.

Lastly, do multiple reviews of the rendered information to your source document. Each review will bring out few errors until you have eliminated all errors. The review should also be done by people who have not actively involved in the XBRL tagging process which can give an independent outlook.

Embedded solutions like Unity XFR make it easier for you to perform the overall mapping/tagging/review process in an iterative manner. So as you review your options for moving XBRL in-house you can keep that in perspective.

The Boards of the Financial Accounting Standards Board (FASB) in the United States and the International Accounting Standards Board (IASB) have developed a series of joint projects to help move US GAAP into alignment or “convergence” with IFRS. In a Memorandum of Understanding, issued in June of 2010, the Boards updated their progress on these various projects, which include topics such as financial instruments, leases and revenue recognition. The Boards update also noted that the changes resulting from these joint projects may have significant impact: in order to allow US companies adequate time to review respond to exposure drafts they will focus on issuing no more than four in a quarter. In a separate statement, Mary Shapiro, SEC chairman, stated that the changes in the timelines of the Boards will not change the 2011 date set for the SEC to determine whether IFRS will be adopted for US SEC reporting entities.

The Issues for Technology:
Most companies at this juncture have evaluated the impacts of IFRS or are in the process of doing so. It is unclear what the technological implications might be for solutions that will support what will certainly be a major shift in accounting practices during this convergence towards more principles-based standards. To date, accounting technology has worked with the algorithms needed to calculate and record transactions in accordance with US GAAP. More principles-based standards allow more expert discernment of scenarios and circumstances in the determination of how transactions will be recorded, which adds a new layer of complexity to the required calculations and the required documentation. Large companies often have five-year roadmaps laying out systems plans, and many businesses have started working towards a 2014 implementation date for their IFRS compliance solutions.

Where Trintech Reporting Software Fits:
The consultants and experts are preparing for the onset of IFRS – in whatever form it will eventually take. There is much helpful literature on how to tackle the issues. Trintech’s Financial GRC platform, Unity, offers an opportunity to support the process optimization which will be the end result of IFRS adoption within technology.

• Documentation and Policy Management: IFRS will require accountants to understand new policies and carefully document positions. Trintech’s platform schedules and delivers personnel the most recent documents, policies and associated templates required to perform tasks in a ubiquitous format called an action plan. Communication will need to be clear and current. Trintech enables a seamless process to keep personnel aligned in task execution, no matter where they might be located.
• Reporting Process Management: IFRS adds a new layer of expertise, review and work management to the reporting process. Companies that manage multiple reporting streams may need to have an IFRS team to manage the convergence to the new standards, and allow regulated and statutory managers to remain focused. The reporting process already has an unwieldy number of review layers and short, tight deadlines. Adding IFRS requirements may strain some reporting processes, resulting in errors or late filings. Trintech’s platform delivers a backbone of business process technology that can manage complex and layered workflow and hierarchies, giving reporting managers the confidence and efficiency they need to get financial documents prepared for release.
• Reporting Collaboration: Management requires executive-level views to IFRS financial statements. The documentation may be much more extensive, and management may require more ready access to literature and supporting memos. For some period there may be a transition, where management wants to see IFRS compared to existing US GAAP. Management will need confidence that numbers have been analyzed and verified, to ensure that they conform to the proper accounting standards. Trintech’s Financial Console presents financial information for IFRS, GAAP or any required reporting standard, in detailed and comparative views, including status tracking to indicate the progress of all required steps.

Conclusion:
Unfortunately there is no magic wand or fancy macro that can transform conversion to IFRS into a push-button exercise. Much work will have to be done by knowledgeable accountants to support the translations and positions taken. Trintech can support the processes by relieving the administrative burdens of managing tasks across the globe, presenting the issues, exceptions and status, and bringing confidence and efficiency to managing the complexities of a revised reporting process under IFRS. Trintech enables the production of a high quality, first draft of IFRS statements via templates to increases the quality and confidence in reported results.

The transition to iXBRL has been the source of much confusion and anxiety, with businesses unsure how to effectively estimate the efforts and costs associated with compliance. The purpose of this solutions memo is to present the challenges surrounding iXBRL compliance, so that business reporting managers can make well-informed decisions about a path forward.

What is iXBRL?
The HMRC mandate dictating the use of iXBRL is yet another in a series of regulations aimed at increasing transparency in business reporting. Typically the business reporting process is a time-pressured one which is highly dependent on a small but mighty group of individuals who manually gather the needed information from a large number of stakeholders, ensuring the appropriate rules are applied and financial documents are delivered in the required formats.

XBRL – eXtensible Business Reporting Language – is a data technology designed to increase interoperability of information between computer systems. XBRL essentially applies contextual information to data – or metadata – which helps systems parse through what might otherwise be confusing tables of raw, and meaningless, information. XBRL has been increasingly adopted by financial institutions and governmental departments across the globe, because its flexibility and interoperability provide unparalleled transparency and insight into business filings.

Because XBRL was designed to facilitate computer-to-computer interaction, however, it can often be difficult for mere humans to parse the output created by systems using the language. XBRL data, while powerful, is quite weak in terms of capturing the rich presentation semantics surrounding business reporting information.

Enter iXBRL, or “inline XBRL”. iXBRL is an evolution of XBRL which contains additional information about how XBRL data should be presented: onscreen, in a statutory account, in a tax filing, or on a printed page. iXBRL essentially merges the formatting of a document with the application of the XBRL metadata, making it much easier (for humans) to view financial data. At the same time XBRL data can be extracted from an iXBRL document, hence preserving the best of both worlds – presentation for humans, and structured data for machines.

Inline XBRL
iXBRL allows humans to interact with XBRL-enabled financial documents in a more user-friendly manner.

The HMRC Mandate
The mandate specifies the minimum acceptable content for a statutory business tax return. For all accounting periods ending on or after 1 April, 2010 and filed on or after 1 April 2011, company tax returns must be filed electronically. HMRC have issued guidance on the requirements for filing iXBRL online, which can be found here: www.hmrc.gov.uk/ct/ct-online/file-return/switching.htm.

The final required filing will be comprised of an iXBRL computation file and statutory accounts file, both of which are attached to the electronic version of the CT600. The mandate covers approximately 1.5 million businesses, and does not affect submissions to Companies House.

Tagging Statutory Accounts with XBRL
HMRC continues to examine the available tags as the XBRL standard evolves, and to update published taxonomies annually as needed. They have also published a minimum set of tags to be used by companies filing according to UK GAAP or UK IFRS standards, with additional tagging requirements to be phased in several years from now (most likely from April 2013). Companies will not need to use each of the tags listed in the minimum tagging requirements taxonomy – only those which apply to the labels in your statutory accounts will be required.

However you choose to tackle compliance, the importance of the “Map >> Tag >> Validate” lifecycle cannot be overstated. Initial mapping is done outside of any software solution by a cross-functional team. Mapping tags to your unique business conditions will help your team size the effort required, and the number of tags you will be required to apply to your statutory accounts. As tagging begins, it is important to validate that the output is what you’ve intended: validate early, and often.

For most companies, adapting to iXBRL requirements will be a catalyst for a re-evaluation of your statutory accounts production processes and systems. And although iXBRL rules increase your reporting requirements, they do not increase the time available for filing. For many companies, periodic filing windows have decreased by a not insignificant amount. Your company can’t afford to sacrifice time from the accounts production process to make up for the increase in reporting effort due to iXBRL.

From a pure business perspective, XBRL’s transparency offers few immediate benefits to filing companies, and plenty of immediate challenges. Depending upon the type of solution you implement, recurrent tagging, validation, and filing requirements can easily overwhelm your business reporting team – especially for businesses filing large numbers of statutory accounts. Strategic solutions will allow XBRL taxonomies, business reporting templates, and specific tags to persist from period-to-period – possibly even featuring shared tag libraries to be used from one statutory account to the next. These time-saving features will significantly reduce compliance efforts after the initial filings are complete, saving valuable time and effort for the ongoing maintenance of any compliance effort. More inexpensive, “quick fix” tools will do just the opposite – placing the greater part of the tagging, validation, and XBRL tag maintenance efforts on your staff, and requiring a greater overall cost of ownership in subsequent periods.

It is becoming clear that simply increasing staff or work hours to handle the increased work will not be a sustainable or strategic solution. Additional staff adds to the cost and complexity of the entire process and the manual effort doesn’t scale. Overworking existing staff adds risk and delays from the inevitable creation of and correction for errors. The challenges are made more complicated when a company has a huge number of statutory accounts.

iXBRL compliance is a recurring technical requirement, and consequently requires a technical solution to achieve strategic goals. That solution is to automate as many of the recurring and repetitive processes required for tagging of statutory accounts content as possible.

Types of Solutions Available
There are three basic avenues to iXBRL compliance:

• Bolt-On Solutions
  • These “helper” software tools allow businesses to apply XBRL tags after statutory account data has been compiled. Bolt-on capabilities are widely available, offer what seems to be low-cost entry into iXBRL compliance, and provide a baseline level of features and functionality to get your team started. Bolt-on tools allow tagging at a near-final step in the business reporting process, but do not allow tagged data or taxonomies to persist from period to period, however (or even from one version of a document to another), and so can require additional manual effort if your team is often editing the data contained within your statutory accounts; for these reasons, total cost of ownership is much higher than the price of the software itself.
• Embedded Solutions
  • The more strategic alternative to a bolt-on tool is an embedded, automated solution. Embedded or “built-in” iXBRL software solutions often integrate XBRL functionality with broader financial governance, risk management, and compliance feature sets, allowing tags, taxonomies, extensions, and even statutory account templates to persist from one period to another. After the initial compliance effort, the efforts required in succeeding periods is often much smaller with an embedded software solution.
• Outsourcing
  • Many businesses offer a combination of software and services which makes it possible to outsource the entire iXBRL compliance effort. However, the expertise required and the multiplier effect seen by businesses filing multiple statutory accounts can make this option expensive and time-consuming.

The Embedded Approach to iXBRL Compliance
The embedded model represents the future of XBRL/iXBRL compliance. It’s true that the other models do have an initial appeal: the lower initial entry fee of a bolt-on tool will win many over in a trial mode for initial compliance, while the hands-free outsourced model provides an illusion of reducing the pressures felt by your business reporting team. But companies with a strategic outlook will seek to own control of the iXBRL tagging process (difficult if not impossible using an outsourced model, as the knowledge surrounding compliance is never captured by the business), and leverage the HMRC mandate to increase the efficiency and reduce the total cost of business reporting efforts (also difficult using a bolt-on tool, as the manual effort to tag, validate, and manage your iXBRL must be repeated from period-to-period, and often from one statutory account to the next).

The embedded approach, on the other hand, allows business to bring iXBRL compliance efforts in-house and – more importantly – to control the strategic decisions surrounding tag management, which will have a positive impact on productivity and reduce costs in successive periods.

Immediate and Recurring Benefits

IMMEDIATE BENEFITS:

• Reduce Manual Labor
• Increase compliance
• Tag once
• Tag at the source
• Validate early and often
• Manage complexity

Embedded solutions provide both immediate and recurring benefits. Immediate benefits include a reduction in repetitive manual labor, increased compliance, the ability to tag a document once rather than having to repeat the tagging process as edits to the document are made, an ability to apply XBRL tags as close to “source” data as possible, and support for frequent validation.

But the recurring benefits are where an embedded solution really begins to pay off for the business.

First, it’s essential that previous XBRL tagging efforts can be carried over to subsequent reports. While the information in each subsequent business filing varies, the output structure and source data are typically very similar. Effort that has gone into tagging these elements and their attributes should be retained across periods as much as possible. Look for the ability to assign tags as meta-data to enable efficient roll-forward.

Also, as described above, consider whether tags can be assigned to the source of data, rather than to output. When an item such as “Gross Annual Revenue” is tagged at the source, an embedded system should be able to automatically fill-in rounding, currency, year, and other related tag parameters.

Secondarily, the ability of the system to adapt to changes over time will greatly affect its long-term benefit. The number of disclosure items required to be tagged could increase dramatically, and the automated system should gracefully expand to support that additional detail. Similarly, the system must adapt to the evolving changes in XBRL taxonomies, and provide tools to help users apply these changes appropriately.

Another important consideration for an XBRL compliance system is its integration with your other financial systems and processes. Beyond the fundamentals of XBRL tagging, some automation systems offer components or extended capabilities that provide additional benefits for more efficient and better-managed business reporting.

One example is workflow management, which enables improved collaboration and “parallel progress” towards tagging, through all the complex iterations of statutory account creation. Other important background capabilities that could benefit your company include automated security, permissions and approvals for creation, deletion and revision of document content, with built-in audit trails and version tracking.

Automated production of the final, formatted statutory account, with support for common file types such as PDF, Microsoft Word, and HTML adds further benefits in efficiency and reduction of errors.

Automation can begin even further upstream, enabling similar efficiencies, cost reductions and error reduction. Automation also allows you to redirect resources to more meaningful analysis of the financial results, providing enhanced information and analysis to executives for more informed decision making and more accurate commentary on performance to the financial markets. In fact, automation can begin at account reconciliation and carry seamlessly through to business reporting, compounding benefits along the way.

Conclusion
In reviewing the capabilities and potential benefits of the two categories of XBRL automation, bolt-on and embedded, the limitations of the bolt-on approach become more apparent.

ASK YOUR VENDOR:

• How does your solution scale to manage a large number of statutory accounts?
• Does your solution maintain tag libraries from one period to another? How are changes to XBRL taxonomy or individual tags managed from one period to another?
• Does your solution allow multiple users to work on the same document at once, regardless of geography or time zone?
• Does your solution support document tagging and tag management for multiple entities?
• Does your tool offer a single repository for multiple reporting entity filings?
• How does your system integrate with other back-end systems?

Bolt-on XBRL solutions, by their nature, yield lower immediate benefits other than a low initial purchase cost. As they are not closely integrated with business reporting systems, they are often more complex to use. They are dependent on the business report as their data source, and typically require more manual re-keying and tag assignment, particularly as the statutory accounts are revised. Bolt-on solutions may require delaying application of tags until the statutory account is final, preventing distribution of the workload, adding a great deal of risk for meeting filing deadlines, and little room for correction of any errors discovered in the process.

Bolt-on solutions also yield fewer recurring benefits, as relatively little of the tagging effort from previous documents carries over to future accounts.

In contrast, embedded XBRL solutions offer far greater immediate benefit, and nearly all past tagging effort applies to future reports. Further, embedded solutions enable other efficiencies and error reduction through sharing of tagging effort, context-awareness of source data to assist in tag selection and validation, and presentation through a software interface that’s already familiar to your users.

The primary advantage of a bolt-on solution — a lower initial cost — is very quickly lost when compared to the higher immediate and recurring benefits from an embedded solution.

The Form 20-F filing included detailed Level 1-4 XBRL tagging, and was completed by a cross-functional team of professionals working under the direction of key Finance stakeholders. Using our proprietary Unity XFR financial reporting solution, with support for embedded XBRL tagging and compliance, the team developed an XBRL taxonomy unique to Trintech’s business conditions, mapped specific XBRL tags to the individual tables, data, and notes within our annual report, and validated that the final XBRL output would comply with SEC guidelines.

Key members of the 20-F filing team will be hosting a webinar to present best practices culled from the project on Wednesday, July 21, 2010 at 1:00 pm CDT. Mike Willis, Chairman of XBRL International and a Partner with PricewaterhouseCoopers, will host the webinar.

Register Now For Trintech’s Webinar on Best Practices in Level 4 XBRL Tagging

• Recurring/Standard Entries: Manual entries made on a regular, periodic (monthly, quarterly) basis. Often judgment-based entries or adjustments due to system limitations, such as reserves or revenue recognition.
• Non-Recurring: Entries that are generally known at the beginning of a period, but will not be repeated in future periods. Often transaction-related, such as an acquisition or sale.
• Ad-Hoc: Entries not anticipated, but that arise due to issues, errors or omissions.  Typical items include reconciliation adjustments, or corrections due to clerical errors.
• Intercompany Reclasses: These warrant calling out separately from ad hoc entries, although the amounts are also unknown.  The volume can be high, but the amounts immaterial. Multi-currency exposure – and the ability to trace to the original source of the transaction – compounds issues surrounding volume and balancing requirements on Intercompany Accounts. The entries tend to be for management reporting purposes and are made for cross business unit charges, such as shared expenses.

Manual entries of any sort are a source of concern, error and inefficiency. The issues related to these entries vary from company to company, depending on their general ledger systems and tolerance levels. However, a few issues continue to rise to the top that warrant consideration.

• “Lifecycle” Documentation is Difficult
  • Unable to attach and store all types of supporting documentation from external applications
  • “Packaging” final journal entry with original support insufficient
• Ad Hoc Entries Require Break in Process
  • Manually interface to ERP to create journal entries
  • Approval processes can be ad hoc
  • Validations to ERPs are as robust or available in manual JE processes
• Intercompany Journal Entries are Excessive and Difficult to Stop
  • Too many journal entries for intercompany reclassification
  • Intercompany manual journal entries are  hard to track and prevent

The solutions to these issues are not as easy as it might appear. Automation is only a part of the puzzle.

The requirements list for an automated journal entry solution should include the following:

• Integration of general ledger validations
• Ability to handle journal entries with one to one, one to many and many to many accounts
• Functionality to tag support with the associated journal entry number from the ERP and report back the result of the JE posting
• “On the fly” workflow
• Capability to have reversing and recurring journal entries
• Support for managing intercompany reclassifications and threshold to limit based on materiality
• Strong reporting tools

Finding ways to bring an agile and flexible solution to aid in the management of these entries is an exciting proposition. There will always be entries that need attention “outside” the box. The agile solution to manage and control these entries is possible.  Companies have the opportunity now to build their requirements lists to request agility, visibility and control.

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.