To err, after all, is only human.

But Trintech’s Unity Suite can help businesses remove human error from the equation altogether. By automating complex reconciliation, review, and exception-resolution processes, Unity enables businesses to achieve significant gains in productivity and internal controls.

Maybe your resolution is geographic expansion. Unity is designed for global commerce. The collaborative architecture allows dispersed teams to co-create documents and oversee complex, automated workflows across regions. Unity supports multiple users working with multiple currencies in multiple languages.

Resolutions are about improving on last year’s efforts. For departments tasked with continuous improvement projects, Unity’s decision-support dashboards can help identify bottlenecks before they occur. Our reporting capabilities allow for complex forecasting, trending, and flux analysis, so your team can learn from the past, and do better in the future.

No matter what your corporate resolutions are, Trintech’s Unity Suite can help. We look forward to enabling an inspired – and inspiring – new year for each of our customers.

• “Automating reconciliation of high volume transactions typically delivers time and cost savings of 30% to 70% with an ROI of 6-9 months.”
• “Automating account reconciliation of GL control accounts typically delivers time and cost savings of 15% to 20% with an ROI of 12+ months.”

- Atos Consulting, Optimizing Your Reconciliation Process, 2011

Competitive businesses are constantly trying to improve on productivity, demanding more and more value from their employees, processes and technology. The term “business process optimization,” still a kind of insider’s phrase even a few years back, has now gone mainstream. And yet, even after realizing dramatic efficiency gains from newer, smarter systems and processes, some business owners find themselves wondering where the next big bump in productivity will come from.

To find the answer, look no further than your balance sheet.

In part due to its somewhat qualitative nature, the balance sheet certification process has managed to elude even the most savvy process optimization efforts. Viewed as a necessary evil, certification often remains a largely fly-by-night process, rife with manual tasks, checklists, and outdated technologies.

But for those who manage to tackle balance sheet certification, understand it, and employ a best practices approach to process consolidation and automation, the bottom-line benefits can be impressive. You saw the quotes at the beginning of this article. These are results that shouldn’t be ignored.

Trintech’s expertise in helping businesses automate all kinds of account reconciliation – from high-volume, transactional accounts to GL control accounts – gives our team on the ground a unique perspective here. That’s why we’ve recently released a new Best Practices Guide to Optimizing Balance Sheet Certification, including seven “golden rules” to consider when embarking upon your own account reconciliation automation project:

1. 1: Organize A Steering Committee
2. 2: Identify Process Gaps
3. 3: Optimize Before You Automate
4. 4: Take a Top-Down, Risk-Based Approach
5. 5: Follow a Structured Project Methodology
6. 6: Optimize in Phases
7. 7: Automation is Your Friend

Over 600 of the world’s leading organizations have successfully optimized their balance sheet certification process using Trintech technology. Download your best practices guide today to find out how you can, too.

>> Download the Best Practices Guide Now

We had the opportunity recently to interview Gianluca Garbellotto, Chairman of the XBRL GL Working Group, about the exciting advancements XBRL Global Ledger promises to bring to the financial close, consolidation, and reporting landscape. Mr. Garbellotto envisions a future where XBRL becomes the “glue” between discrete and traditionally disconnected software platforms – enabling businesses to capture, utilize, and leverage financial information along the entire Finance supply chain. The result? A Finance function fit for the twenty-first century, featuring lower costs, less headache, and greater access to (and use of) actionable business intelligence.

Q: What is XBRL GL?

A: XBRL GL is an XBRL taxonomy developed and maintained by XBRL International Inc.(XII) that provides a standardized representation of:

• Detailed / Transactional Data
  • Invoices, orders, journal entries etc. – and ledgers/sub-ledgers –General Ledger, AP/AR, Inventory, Fixed Assets, Payroll, and other detail oriented information.
  • Basically, a standardized representation of the structure of a typical accounting/ERP application, and the reason why something like this is important is because it enables consistent access, visualization and analysis of data no matter in what software package it resides in.
• Data Structure
  • The rules for the aggregation of this information into financial or other reports, typically represented by XBRL taxonomies or other XML oriented formats, for internal or external reporting purposes.

Q: What is XBRL GL used for?

A: In isolation, XBRL GL is used for data migration, data archival, data integration, consolidation, as a payload for Web-services-oriented architectures, for auditing and compliance, for tax reconciliations, for sustainability reporting, and more.

But when used alongside XBRL for financial reporting, XBRL GL acts as a bridge between transactions and end reporting and for reconciliation between different summarized end reports originating from the same underlying granular information.

Q: Who is using XBRL GL?

A: Since XBRL GL is about leveraging XBRL internally, its implementations are not as publicly visible as your typical XBRL project, which is mostly about external reporting. Having said that, users that decided to share their experiences publicly include Wacoal, a global manufacturer of apparel with headquarters in Kyoto, Japan, who used XBRL GL to integrate a total of 32 independent information systems in use in 36 subsidiaries throughout the world; the State of Nevada, whose Controller Kim Wallin led an XBRL GL based initiative around grants reporting; and Fujitsu, which adopted XBRL GL for its internal use in a project with the same features of Wacoal’s, and on an even broader scale. At the US Federal Government level the Department of Housing and Urban Development (HUD) has deployed an XBRL GL solution for the collection of mortgage and property management related transactions. Recently the Maryland Association of CPAs and Altova published a case study that showcases how non-profit organizations and small businesses can benefit from the adoption of XBRL GL both to streamline their internal reporting processes and for regulatory compliance.

Q: Who maintains the XBRL GL standard? Is it “complete”?

A: XBRL GL is the only taxonomy developed and maintained directly by XBRL International Inc. The current release is a RECOMMENDATION of XII since April 2007, and the various implementations based on it have not produced any significant request for changes or enhancements. This means that XBRL GL has proven to be comprehensive and stable. While further market requirements could drive the development of additional modules in the future, it is expected that the core foundation of XBRL GL and the modules already developed will not change significantly.

Q: How will XBRL GL change the way financial reporting managers and other financial professionals do business? Will there be tangible evidence of changes in process, technology, or reporting because of XBRL GL?

A: The deployment of applications that leverage the XBRL GL data model enables the “ownership” of corporate data and related processes in ways that are just not achievable with more traditional approaches. Lower costs, greater efficiencies coming from the automation of manual processes and the ability to view, analyze and share data using common templates and validation/business rules across different applications and IT infrastructures are just a few examples of the way in which XBRL GL and data standardization in general profoundly transforms the way in which the financial function produces and consumes corporate information.

Q: What implications does XBRL GL have for enterprise software vendors? How will these players adapt to the changing requirements of their customers?

A: XBRL GL represents both a challenge and an opportunity for accounting software and ERP vendors. A challenge, because it “liberates” corporate data from the proprietary formats in which it is created/stored, and as such it is sometimes perceived as a facilitating factor in the decision of switching to another product. An opportunity, because XBRL GL addresses “pain points” in data integration and reporting processes that are common in any corporate environment, and not necessarily, or even normally, solved by traditional proprietary approaches – the common proliferation of Excel spreadsheets to perform integration and assembly of data even where ERP applications that are supposed to integrate all the information and reporting needs are in place is evidence of this.

Q: What about the investor community? How will XBRL GL allow them to evaluate risk and opportunity in the years ahead (if at all)?

A: I will answer the question from the broader perspective of data consumers in general, which include investors and analysts but also regulators. Even those who don’t see internal data still care about internal data. XBRL GL can facilitate the improvement of the quality of data being reported upon, whereas external reporting agreements primarily improve the data transfer of today’s quality of data.

Q: How might XBRL GL affect businesses who do business internationally?

A: This is really one of the “sweet spots” of XBRL GL. In the situation you just described the possibility of leveraging a standardized, free and application independent format to reconcile between different jurisdictional reporting obligations can make a real difference for global businesses by enabling automation of processes that are currently mainly manual, and ultimately translates in significant efficiencies and cost savings.

Q: What excites you most about the future of XBRL GL?

A: XBRL has been very successful in becoming the global standard for financial reporting in a relatively short period of time. The adoption process so far has focused almost exclusively on the benefits for data consumers – regulators, analysts, investors. Transparency and comparability of financial information are obviously significant benefits for everyone in the business community, but a real value proposition for data producers only comes from the ability to do something better, cheaper or preferably both in daily operations. XBRL GL provides that ability, and as such it is the full realization of the benefits of XBRL.

To learn more about how Trintech can help you automate XBRL tagging, compliance, and reporting, read up on our Unity XFR solution today.

ABOUT GIANLUCA GARBELLOTTO:

Gianluca Garbellotto is a globally acknowledged expert on the business and technical aspects of the Extensible Business Reporting Language (XBRL) and XBRL Global Ledger Framework (XBRL GL), and has extensive experience in their implementation in the government and the private sector. He is the current Chair of the XBRL Global Ledger Working Group,, a past member of the XBRL Standards Board, and a member of the Institute of Management Accountants (IMA) XBRL Advisory Group.

He has extensive experience in the banking and financial industry as well as in accounting and financial software development and implementation, with a specific focus on ERP systems, consolidation/business intelligence applications and XML/XBRL implementations. His clients’ portfolio includes governments in various countries and global companies as well as leading professional, consulting and technology firms.

Corporate website: www.iphix.net
Blog: www.glg.iphix.net

Software vendors have taken notice. Recent years have seen a proliferation of data-driven software solutions, with polished pitches promising to automate everything from data capture and delivery to financial reporting and compliance (and everything in between). Even the engineering department is getting in on finance, repurposing data standardization tools like XBRL for use in specific financial processes.

But as Finance Managers window shop for process enforcement technology, many lose sight of larger finance goals, seeking a piece of software purpose-built to handle a specific process, department or geography. Software is a key enforcer of finance process … but it is rarely the answer to successful Finance Transformation. `

You’d think that, as a software vendor, we might want to keep a lid on this dirty little secret. But it’s true: focusing too heavily on the bells and whistles offered by any one technology package – without first creating a compliance strategy unique to your industry, your business, and your people – is a recipe for an under-utilized software installation. One which fails to provide the desired enterprise benefits. Software configuration options to support finance transformation run the gamut, from “pre-packaged” on the cloud, to fully-customized solutions. For most global finance organizations, the answer is somewhere in the “configurable” middle.

In the mid to late 1990’s, “vanilla” E.R.P. systems were all the rage. “Vanilla” offered the opportunity to get a system up and running quickly, replete with basic functionality to support rapid growth – at a time when insight to revenues and “flash” reports were most critical. But more advanced finance operations suffered, becoming increasingly complex as a result. Businesses rushed to install something, anything, that could be tagged with an E.R.P. moniker – only to discover when Sarbanes-Oxley arrived that, in the rush, they had sacrificed too many controls. The tools were under-utilized, resource planning efforts were abandoned, and the cost of those remediations was, for many, quite high.

Technology installed “for technology’s sake” can result in great process inefficiencies. Problems begin with a poor implementation, and are compounded by inadequate training or support. These systems are often ignored, or become redundant tools required to appease management. Highly customized technology often becomes very difficult to maintain, creating tension between IT and finance, or building a barrier to the necessary changes in process. These systems are then intertwined with a faulty workflow, complicating reporting and daily operations.

Many businesses look to the rapid and efficient adoption of sales automation as an example of how finance technology might be more easily deployed. But this model is flawed: while smaller, centralized finance operations with a single set of compliance standards might benefit from this “one size fits all” approach, it is rarely effective for most global operations.

Global finance is different from sales force automation. Finance is guided by a set of requirements – both internal and external – based upon a variety of subjective, but important, factors. The complexities of geography, your supply chain, business model, industry vertical, and competitive environment, must all be incorporated into your internal financial lifecycle for process change to deliver the requisite savings in time, money, and transparency. Choosing, for instance, which accounts to reconcile has a qualitative component, warranting consideration of flexible technology to support that choice. Not all reconciliation packages allow for innovative matching and exception management workflows, or allow the modeling of custom account templates to drive needed metrics.

At the other end of the spectrum, a fully custom-built solution is rarely the answer. Such systems are cost-prohibitive to install and maintain. But abandoning technology, to focus instead on re-engineering your financial processes in a vacuum, isn’t the answer either. This might result in short cuts. For example, a company might decide to localize close task management – unaware that technology can automate this process centrally.

Technology is a good enforcer. And when you’re trying to standardize processes across a wide spectrum of financial activities, technology can often be helpful in overcoming the inertia of years, sometimes decades, of established business practices. Technology can establish parameters around specific tasks, monitor inputs, track changes, and create searchable, auditable records for compliance purposes. Technology supporting the required process frameworks for finance operations, but still configurable enough to meet specific cultural and company practices, seems to be the most successful for global finance organizations.

When embarking on a Finance Transformation Initiative, the choice of tools should be an integral part of the process, not something done after the processes have been designed. Limiting your design options due to faulty assumptions about technological capabilities will undermine the effort. Here are a few rules of thumb:

Rule #1: Assume Everything Can Be Automated
Automation should provide the foundation for your initial discussion about process redesign. Invite as many diverse stakeholders as possible into the tent – including I.T. These stakeholders will come to the table with a wealth of experience, a plethora of “pain points” needing automation or management. As your diverse team of experts reworks your business’s finance tasks on paper, have them assume that a package exists to automate these onerous tasks (even if you’re not sure). Then seek out vendors with the flexibility to automate as much of your custom process as is plausible and cost-effective.

Rule #2: Assume A Risk-Based Perspective
When reworking your entire financial work flow, try to automate those areas which could expose the business to future risk, rather than automating based upon existing roles or perceived ease-of-use. Many technology vendors will offer a starting point for this sort of analysis, packages of pre-built templates, calculators, or consolidation and conversion technologies. Take these starting points, and tweak from there.

At the end of the day, you may not get everything you wanted. But you’ll have a more engaged and enthusiastic team of stakeholders, excited about implementing the changes coming down the road.

Rule #3: You Don’t Buy A Vendor, You Buy Their Tools … AND Their Vision
Software vendors are always attempting to stay ahead of the curve. Make sure you understand your vendor’s vision – it should map closely to your own. Choose a vendor with a similar philosophy, one who is willing to share their product roadmap, and help you imagine how your can achieve your desired business transformation together.

And financial governance is one huge problem facing many finance managers.

But in the rush to comply with what can seem like an overwhelming landscape of financial regulations, businesses can lose sight of the bigger picture. Compliance with any given regulation should arise naturally, as a side-effect of sound practices governing the Office of Finance. All too often, however, regulatory compliance becomes both the means AND the end, as organizations adapt their financial governance processes into limited feature sets offered by vendors selling compliance with a regulation or business problem of limited scope.

Prior to implementing our Unity Financial GRC Software Suite, several of our clients had been utilizing no less than five compliance packages, each one purchased in the hopes that it might be the “magic bullet”, rapidly transforming their business into a profitable (and compliant) organization. The results are usually less spectacular than advertised: manual workarounds or home-grown solutions are often required to transmit data between these multiple applications, and complicated, custom-built reports must be kludged together in order to give senior decision-makers the information they need to run the business.

By focusing on compliance alone, many software vendors make financial compliance more difficult to achieve (at best) and less likely to occur (at worst).

A more practical approach to financial governance instead streamlines the entire finance lifecycle – from data capture, to customer transaction management, to bank and general ledger reconcilitation, to exception management and resolution, on through to the financial close, financial reporting, and auditor communication. This more holistic view of the Office of Finance allows businesses to focus on developing a healthy process as a means to eventual regulatory compliance.

At this time in most finance organizations, reengineering at the process level has occurred. Even if this reengineering has not yet been fully implemented, these finance transformation projects have distilled an established set of “best practices”. The technologies to embed those best practices into daily workflow are often misaligned with the overall transformation initiatives. The result is a feudal system of warring departments, each fending for itself, hoping that a discretionary budget can help purchase a “magic bullet” to solve its compliance issues.

But the “magic bullet” just doesn’t exist – these bullets might arm one department with the weapons necessary for compliance, while doing damage to other groups, creating inefficiency and additional work for everyone involved.

To avoid this “magic bullet” syndrome, look for three basic characteristics when evaluating a holistic financial governance software package:

• Extensibility:
  • A modular application architecture should allow your business to “start small” (often in the area causing your business the most pain) and grow into compliance over time. Evaluate the vendor’s responsiveness, the system’s feature set, and your own appetite for radical process transformation prior to moving forward with an enterprise-wide implementation.
• Scalability:
  • Make sure that the solution is capable of growing along with your business. There are many excellent single-point solutions out there which perform well up to a certain user or data threshold, after which they become effectively useless. Don’t let this happen to you.
• Flexibility:
  • Your financial governance process is the most important component of your business and compliance strategy. Too many solutions will require you to cut corners in order to fit your process into a feature set of limited scope. Your process should be supported by the system you select, and not the other way around.

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.