Will software vendors be ready for COREP reporting?

The new CRD IV banking directive is about to take effect.  But how prepared are the traditional banking software vendors to help their clients issue their first reports?

From April the UK Financial Conduct Authority (FCA), for example, will be collecting the first COREP reports in the new XBRL (eXtensible Business Reporting Language) format against the taxonomy issued by the European Banking Authority.

There are, however, growing concerns around the availability of fully functional, XBRL-enabled software in time to meet the deadlines imposed by the new reporting regime.  Several traditional suppliers are likely to fail to meet the due date, especially as changes to the taxonomy may occur even at this late stage, and those with hard-coded solutions may struggle to implement the necessary changes in time.

However, there is an alternative for beleaguered vendors.

CoreFiling is offering a rapid enablement option to help vendors over the first reporting hurdle, followed by further assistance to XBRL-enable their offerings.

To overcome the immediate reporting obstacle, CoreFiling’s Seahorse® provides simple to use, SaaS-based  Zero-Tag™ technology for the generation of Excel forms that, when completed, are seamlessly turned into compliant XBRL documents ready for submission.

In a second phase, vendors can then take advantage of CoreFiling’s in-depth XBRL expertise to incorporate fully standards-based components into their offerings and ensure the output of fully valid XBRL documents.  True North®, CoreFiling’s flagship XBRL processor and validator, is a key element in this second stage.  It’s the component of choice for the FCA’s own EBA reporting requirements and validation of COREP and FINREP filings received from the UK financial market, so vendors can be sure they are validating documents to the same exacting standards as the regulator.

Explore the GRI Taxonomy with the help of Yeti

The latest addition to CoreFiling’s Yeti® taxonomy exploration environment is the GRI (Global Reporting Initiative™) Taxonomy 2013, launched on 7th November.

Developed in association with Deloitte, the GRI Taxonomy 2013 is designed to allow companies to begin producing sustainability reports in XBRL in accordance with the G4 guidelines.  The GRI aims to promote a more sustainable worldwide economy, with particular focus on ethical behaviour, social justice and environmental care.

Although sustainability reporting in XBRL has not yet been mandated, the GRI has launched a Voluntary Filing Programme (see: https://www.globalreporting.org/reporting/reporting-support/xbrl/Pages/Voluntary-Filing-Program.aspx) to encourage organisations to begin creating XBRL disclosures that investors and other stakeholders can then review and compare.

In support of this initiative, Yeti lets users gain an insight into the new taxonomy by presenting the underlying concepts simply and clearly.  Even beginners will appreciate the intuitive navigation assistance and powerful search facilities, which make it easy to drill down into the detail and to find particular concepts.

Start exploring the new GRI taxonomy today!  There’s easy access at http://bigfoot.corefiling.com/yeti/resources/yeti-gwt/Yeti.jsp

Worry-free taxonomy development

One thing we’re really proud of here at CoreFiling is our ability to deliver the highest quality software.  We employ exceedingly bright, highly skilled software engineers, developing code using Agile methodologies.

However, the one thing on which we constantly rely to ensure top quality output is our own continuous integration product, Decimate®.  It not only underpins our own development philosophy but is also made available to our customers, and plays an important role in ensuring the success of client taxonomy development projects. In fact, Decimate can support the overall build-test-release cycle of any development project.

The main advantage of using the continuous integration philosophy is that it provides on-going quality assurance and testing throughout the process.  Developers do not have to wait until they are finally ready to release to discover build failures.  Decimate confers a higher degree of confidence to the development process.

Typical development projects involve several people working on the same files simultaneously.  Without a common repository for the seamless merging of changes, chaos is likely to ensue. Dependencies between files need to be handled effectively as there may be unforeseen impacts from one to another.  Decimate guards against these potential pitfalls behind the scenes, by packaging and automatically testing the latest version every time a user makes changes to the taxonomy and confirms those changes back into the central repository.

What’s more, if the build encounters problems, Decimate gives developers very useful information to help determine the source of the issue so it can be corrected prior to the next build.  It’s colour-coded too, for ease of review.

Get ahead with your taxonomy development project with Decimate!  It’s the worry-free option.

Learn more at:  http://www.corefiling.com/products/decimate.html

How fair are the new banking regulations coming out of Brussels?

Sharon Bowles, one of the most influential Britons in Brussels, will be talking about this on Monday in London.  She will talk in her keynote address at “Preparing for CRD IV Reporting” about the challenges facing the banking community and how CRD IV will impact on it.  In the forefront of the drive to improve European banking regulation since the financial crisis, Sharon has devoted herself to building a regulatory system which will provide stability in Europe without putting unfair pressure on the City of London.

The keynote address is one of a series of addresses from speakers across the European regulatory community including the European Central Bank and speakers with long experience at the International Monetary Fund and national regulators.

There are only three days before the conference!

Register now

The conference will also be open to registration from 8 a.m. on the day of the event.

Are you ready for the CRDIV mandate?

Important changes in bank reporting under CRD IV, the new Capital Requirements Directive, the European enactment of the Basel III legislation, are due to come into force starting from 1st January 2014.

Time is rapidly running out. Despite this, there is evidence to suggest that few banks are gearing up to ensure that their internal processes are ‘fit for purpose’ for the arrival of the new reporting regime.

One reason is that there is still a great deal of confusion about what the new regulations actually entail. This is particularly true for the XBRL technology and related taxonomies required to turn the new reporting regime into reality. It is expected that those taxonomies will not emerge in their final form until the end of the third quarter of 2013, giving very little time before the first COREP reports need to be submitted on 1st Jan 2014.

The issue is also blurred by the continued political debate in the European Parliament about bankers’ bonuses, making people believe that this is the only issue. Clearly this is not the case.

The CRD IV reporting changes in fact go much deeper.

Under the new CRD IV regulations, all of Europe’s banks will have to file increased amounts of exposure and risk data to their respective regulators. It may seem like an additional burden, but handled properly this new data will not only help the banks to gain a competitive edge, but might also prevent another bank collapse.

The ‘Preparing for CRD IV reporting’ conference on June 17th at the London Hilton on Park Lane provides a timely opportunity for regulators to explain the case for the new regulation and for banks to gain valuable insight into the reporting changes and how they might turn them to their advantage.

The conference focuses squarely on the regulatory aspects of CRD IV/Basel III and the underlying business issues, with passing mention of the technology that will underpin the submission of the enhanced reports.

During the business track, presenters will explore the issue of ROI and how, by implementing the new compliance requirements correctly, banks will have the opportunity to outperform their competitors. At the moment, many banks view the new regime only in terms of additional investment. The ROI session answers these concerns and explains why investment in compliance will be abundantly worthwhile. However, doing it properly is the key, and there are issues that need to be fully thought through, e.g. How can the new reports be pulled together? How are they to be approved and signed off? How can banks ensure that data is consistent across all submissions made to their various regulatory bodies?

Both the business and the technical tracks will be highly interactive, with ample time devoted to Q&A allowing delegates to enter into the discussion. The conference also features three key representatives from the EBA, the body responsible for translating the technical standards from the legislative requirements behind the new reporting regime. There’s a chance to quiz the EBA further about the ITS (Implementing Technical Standards) which is key to the process, yet not expected to be finalised until later this year.

It promises to be an interesting debate.

For more information and registration: http://www.xbrl.org.uk/conference/

XBRL comes of age with Basel III reporting

Europe’s new Basel III capital regulations, newly enacted as CRD IV, will introduce XBRL-based data reporting to new sectors and markets. In what is arguably the biggest upheaval in European banking since the introduction of the Euro, CRD IV will mandate the collection of increasing amounts of banking capital and exposure data throughout the countries of the European Union. For the first time, XBRL will be at the heart of Europe’s financial regulatory systems, joining the tax authorities and business registers who have hitherto been pioneers of XBRL-based business reporting in Europe.

The main players in this drama will be present at a major conference in London on 17 June, “Preparing for CRD IV Reporting”. Chaired by Robert Driver, the British Bankers’ Association’s Policy Expert on COREP and FINREP, the conference will explore the new regulatory environment with speakers from the European Parliament and the European Central Bank, and will discuss the implications of the new regime for both banks and regulators. Presentation topics will include:

  • Regulatory objectives in processing XBRL-based big data
  • Driving financial outperformance through compliance
  • Improving ROI in financial reporting
  • The use of XBRL standards in reducing the reporting burden
  • Ensuring traceability and consistency in XBRL reporting
  • Management challenges around regulatory reporting

Further details….

So CRD IV has been agreed, what about the ITS?

The last public draft of the EBA’s model for implementing technical standards on supervisory reporting (the ITS) was issued on 15 March 2013. That was followed on 16 April with the approval of the CRD IV by the European Parliament. So the banks are expecting to have their data reporting systems ready by 1 January 2014 – but they can’t put them in place until the ITS has been finalised.

The EBA is expecting to deliver the ITS, to schedule, in good time for the banks to comply. But financial institutions wanting to start planning on the basis of the draft ITS are at risk unless they can be confident about the shape of the final version. Fortunately, help is at hand.

The EBA is supporting a major compliance conference, “Preparing for CRD IV Reporting” in London on 17 June. Andreas Weller, Head of IT at the EBA, and his colleagues Meri Rimmanen and Wolfgang Strohbach, will be present, with presentations covering their expectations for COREP and FINREP. The format of the sessions, with plenty of time for questions from the audience, will be ideal for in depth discussion of the features being planned for the final version. The conference will be a timely opportunity to put your questions to the authors of the ITS.

The EBA’s presentations will be followed by sessions with implementation experts from Deloitte, IBM and other firms covering the strategic issues around investments in compliance under the new regime.

For more details and registration: http://xbrl.org.uk/conference/

New Public Working Draft of Table Linkbase Specification

XBRL International has announced the publication of a new Public Working Draft of the Table Linkbase specification.  This specification forms a key component of the Solvency II and CRD IV XBRL reporting projects.  This release is the first Public Working Draft since 2011, and represents a significant step forward in the maturity and quality of the specification.

Projects that have looked to adopt the Table Linkbase specification have been held back by a lack of recent public releases of the specification, creating interoperability problems as projects have adopted customised versions of the published schemas and standards.

The latest release of the specification has been driven forward by the efforts of CoreFiling staff, and in particular, Jon Siddle.  CoreFiling contributions have included the introduction of an XML serialised “infoset” for defining and testing the conformance of Table Linkbase processors, and the refactoring of the specification into three separate models (Definition, Structural and Rendering) to give a clear separation between syntax and semantics.

These improvements to the foundation of the specification will accelerate the development of the standard towards becoming an XBRL International Recommendation, and will help address the interoperability issues that have beset early adopters of the specification.

Financial reporting has sign conventions, XBRL has a rule

In my previous post, I looked at how a lack of clear best practice around the naming of concepts and elements has contributed to the confusion around sign conventions in XBRL.  I believe that another contributing factor is that the sign conventions used in financial statements are not trivial, and actually quite subtle.

Let’s take another look at the example from my first post:

Turnover 518 498
Cost of sales (321) (299)
Gross profit 197 199
Administrative expenses (211) (105)
Operating profit/(loss) (14) 94

You might also encounter a different presentation of exactly the same data:

Turnover 518 498
Cost of sales 321 299
Gross profit 197 199
Administrative expenses 211 105
Operating profit/(loss) (14) 94

Different jurisdictions seem to converge on one approach or the other, but the point is that either approach is valid.  The same is not true in XBRL.  When it comes to signs in XBRL, there’s a right way to do it, and a wrong way to do it.

In the above examples, we changed the sign of certain numbers on the statement, but we did not change the meaning.  If you change the sign of a number reported in XBRL you will always change the meaning.

When humans read financial statements, they use domain knowledge and context to correctly understand the figures.  I know that companies do not usually report a negative cost of sales (domain knowledge), and a quick check of the figures above and below (context) confirms that in neither case are the suppliers paying the company!

XBRL facts are designed to be understood independently, without the need for context or domain knowledge.

To illustrate the issue, imagine the accounts above had an additional line item:

Taxation 100 (50)

In one year the company paid tax, and in the other it received a tax credit, but which was which?  In the context of the first table, I’d expect this to represent a tax credit of 100 and a tax charge of 50, but in the context of the second table, I’d assume the opposite meaning.  Without the context, it’s completely ambiguous.

By contrast, the sign to be used in XBRL is completely prescribed.  Ask the question, “What was the taxation?” If you answer “100”, then tag a positive number.  If you answer “actually, there was a tax credit of 100” then tag a negative number.

In the last two posts we’ve seen that tagging a value with the correct sign in XBRL is easy, provided that:

  1. You can correctly understand the figure that you are looking at, and you may have to use context and domain knowledge to do this (even if you don’t realise that that is what you are doing); and
  2. The meaning of the concept (which includes its sign convention) is accurately captured in its name.

If you’ve been following XBRL for a while, you might be surprised that I’ve got this far with no mention of balance attributes.  We can’t avoid them forever, so in my next post I’ll be looking at whether they have anything to add, or if they merely contribute to the confusion.

Getting the sign right: Names, labels, and extensions

In my previous article, I demonstrated a simple technique for getting the correct sign when tagging a number in XBRL.  You may have noticed that I was somewhat casual with the notion of concepts having a “name”.  If you’re familiar with the details of XBRL, you’ll know that concepts have an “element name” and typically have at least one label.  Which of these was I referring to?

It is common practice in XBRL to use the standard label to give a concept a human readable name.  The purpose of a name is to unambiguously identify the meaning of a concept, and part of that meaning is the sign convention.  Making a profit and making a loss are two very different things, and if the name of the concept doesn’t make it clear which of these things the concept represents, then it’s not a very good name.

Examples of good names would include:

  • Profit
  • Profit/(Loss)
  • Increase in Accounts Receivable
  • Increase/(Decrease) in Accounts Receivable

Examples of bad names would include:

  • Profit or Loss
  • Change in Accounts Receivable

(the last one is border line – you might reasonably assume that a positive “change” is an increase, but it’s not explicit, and it’s not the sign convention that you’d expect to see used when displaying the concept on a Cash Flow statement)

A more unconventional name like “(Increase)/Decrease in Accounts Receivable” would also be acceptable but note that this is a different concept to one called “Increase/(Decrease) in Accounts Receivable”.

If the idea that a concept should have a name, and that that name should make it clear what the concept means is sounding a bit obvious, then good – it is obvious!

The problem with element names

A concept also needs to have an element name.  This serves a different purpose, which is to provide a unique identifier for the concept in an XML document.  Human readability is not the primary concern, although most implementations have chosen to use meaningful names (e.g. ProfitBeforeTax), rather than arbitrarily generated identifiers (e.g. “c1234”).

XML imposes some constraints on what constitutes a legal element name, most importantly disallowing spaces and most punctuation.  This means that we can’t simply use the standard label as an element name.  Most implementations have adopted an approach of taking the standard label, stripping out punctuation and removing some connective words such as “and”.  This approach is encouraged by FRTA, although an exact rule is not spelt out.

The approach has the unfortunate side effect of turning clear concept names (i.e. standard labels) into rather more ambiguous element names.  For example:

Concept Name         Element Name
Profit/(Loss) ProfitLoss
Increase/(Decrease) in Accounts Receivable IncreaseDecreaseInAccountsReceivable

Such names undermine the notion that XBRL concepts have a clear and unalterable meaning, and that that meaning includes the sign convention.  I suspect that elements such as the above have caused at least some of the confusion about how signs work in XBRL.

There is a very simple approach that would remove this confusion, but it’s not one that has made it into any published best practice that I am aware of, and that is to drop portions of the label that indicate the negated meaning when forming an element name.  For example:

Concept Name         Element Name
Profit/(Loss) Profit
Increase/(Decrease) in Accounts Receivable IncreaseInAccountsReceivable

If you’re uneasy about this approach, remember that the element is just a unique identifier.  It is not intended to be a descriptive label, so the fact that it does not spell out the meaning of a negative value is unimportant.

Extensions and the SEC

In my view, the confusion around signs in XBRL has been fuelled by a number of details of the implementation of XBRL at the SEC.  In the SEC implementation, preparers submit not only an instance document, but also an extension taxonomy allowing preparers to customise the taxonomy to better match their financial statements.

The SEC rule (33-9002) that enabled the use of XBRL for SEC Filings, requires filers to change the labels of standard concepts in the US GAAP taxonomy to match those on the company’s financial statements.  You can argue about whether that’s a good idea or not, but doing so opens the door to confusion around sign conventions.

The text of the rule gives the example of a company relabeling “Gross Profit” as “Gross Margin” as they are “definitionally the same”.  Seems harmless enough, but what about if the line item in your financial statements is “(Increase)/Decrease in Accounts Receivable”?  Should you change the standard label of the US-GAAP concept from “Increase/(Decrease) in Accounts Receivable” to “(Increase)/Decrease in Accounts Receivable”?  In my view doing so is absolutely unacceptable: an increase in accounts receivable is not the same as a decrease in accounts receivable, so changing the name of a concept in this way is very misleading.

The SEC system does provide an appropriate way to handle this situation (negating labels) but the guidance in the Edgar Filing Manual could be clearer.  Rule 6.11.1 instructs filers to “Assign a label of an element used in an instance the same text as the corresponding line item in the original HTML/ASCII document” but nowhere in this rule does it suggest that assigning a standard label that implies the opposite sign convention is unacceptable.  6.11.6 explains how to use negating labels, but does not explain what you should do with the standard label.

Proposed new best practice

I believe that much of the confusion around XBRL sign conventions could be removed by clearly documenting two pieces of best practice:

  1. The element name must reflect the meaning of a positive value reported against the concept.  If the element name is being formed from the standard label, parenthetical indications of negative meanings should be removed.  In other words, a concept called “Profit/(Loss)” should result in an element name of “Profit” not “ProfitLoss”.
  2. When using an extension taxonomy to re-label concepts, it is never acceptable for a standard label to change the meaning of a concept, and meaning includes sign.  For example, “Increase/(Decrease) in Accounts Receivable” must not be re-labelled as “(Increase)/Decrease in Accounts Receivable”.  The correct place for such a label is as a negated label.