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

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.

• 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.

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.