Name: Avoiding Common Errors in XBRL with Special Guest Mike Willis, PwC Date: October 6, 2011 1:00 PM ET Additional Info: Panelists – Raul Varela, CFA (Rivet Software); Mike Willis, CPA (PwC); Phil Mennona, CPA (Rivet Software) View webinar transcript »

Filers should take a moment to review the new SEC Staff Observations.  Most of these observations reemphasize areas discussed in previous Staff Observations, including Rendering, Negative Values, Extended Elements, and Completeness of Tagging.  It should be noted that since the SEC has included many of these same items in previous Staff Observations, it is likely indicative that the SEC is still continuing to see these issues in XBRL filings.  Accordingly, filers should review these Staff Observations to help them avoid common issues cited by the SEC. 

One new area that is included in the Staff Observations is a discussion (an SEC reminder) that some registration statements require XBRL.  When filers submit registration statements with the SEC, they should be particularly careful to comply with any required interactive data rules as failure to comply will result in the loss of short form eligibility until remedied.

For more information, check out the SEC Staff Observations from December 13, 2011.

- Phil

The final part of my blog will discuss units of measure which is another common area of focus by auditors.

First, let’s talk about the importance of units of measure. This concept is usually pretty obvious to most accountants. Some disclosures of monetary amounts may be expressed in US Dollars while other disclosures could be reported in a foreign currency such as Yen. XBRL provides a special attribute called the “unit reference” which distinguishes the units of measure among the values provided in your XBRL formatted information. An example of this is the importance of distinguishing retail organization disclosures made by domestic entities using square feet from foreign companies that may report this information in square meters.

The XBRL specification includes standard ways to report currencies. In an effort to help standardize additional units of measure, XBRL US has provided guidance in its October 18, 2010 Resolutions with respect to units for common disclosures such as Area, Volume, and Length.

The tricky part of units of measure is the SEC also requires units for items like “stores” or “customers” and these units are not currently defined in any standard way among the current XBRL landscape. The first observation about the SEC requirement is it may not always be easy to understand the importance of a unit of “stores.” For example, if there is a disclosure of “Number of Retail Stores,” there really is no other unit of measure that could seem appropriate for this element other than “stores.” This is inherently different than other units of measures, like gallons for example, which could be expressed by another unit such as liters and therefore important for the unit reference to make the distinction. For these reasons, adding a unit reference of “stores” may seem redundant or insignificant to some filers given the unit of measure may not really add much value to the information being provided in the XBRL data.

Also, since unit items such as “stores” are not currently standardized, filers need to create custom units for these disclosures. A unit of “stores” may be defined by another filer as “shops” and yet another filer as “shoppes.” When units with the same meaning are defined differently, it can become increasingly difficult to use and analyze the data provided to the SEC.

XBRL International is currently working on a Units Registry which intends to standardize many units. Once complete, it is likely the SEC will adopt the registry. Until then, filers are required to create custom units without a lot of guidance. Everyone can appreciate the impact and necessity to report the units of measure correctly for currency disclosures in USD or Yen. However, you may decide to assess lower risk related to unit information for “customers” and “stores” knowing that the unit information may be relatively self-evident from the element’s definition. If users are unlikely to get misled by the reporting of “Number of Retail Stores” regardless of the unit used, then there may be lower litigation risk for these items.

In conclusion, this topic brings me back to the most important thing I want to convey to filers in this blog series. Just like most organization’s consolidated financial statements are not “perfect” to the penny, your XBRL filing is not likely to be “perfect” either. Auditor or 3rd party reviews of XBRL data can be extremely valuable in identifying exceptions or potential shortcomings in the XBRL data, but many of these findings should be prioritized or put in perspective based on impact or you may risk dedicating effort in the wrong areas. Often some of the findings are significant, while others may be less important and filers struggle to distinguish between the two. Unfortunately, I have seen countless filers get hung up on things like the units of measure for the “Number of Stores,” literally spending several hours on the issue. These same filers may not spend even close to the same amount of time scrutinizing appropriate element selections, or incorrect negative values, which are areas probably much more likely to result in greater impact and potential liability.

As more and more filers adopt XBRL solutions that are built into their reporting platforms, the checks and reviews for many of the items discussed in this blog series will become automated or covered by systemic controls. The pursuit of “perfect” XBRL will certainly be aided by the adoption of these more sophisticated implementations. Until then, I hope this blog series helped you better understand and evaluate the relative importance of some of the findings usually identified by XBRL advisors.

Related blogs:

Part 1 – Your XBRL Filing Is Not Perfect »

Part 2 – Negative Values in XBRL Filings »

Part 3 – Decimals Attribute in XBRL Filings »

Part 4 – Calculation Relationships in XBRL Filings »

Part 5 – Calculation Validation in XBRL Filings »

Part 6 – Units of Measure in XBRL Filings »

The previous blog discussed a few considerations and limitations when including calculation relationships in the XBRL exhibits. In this section I will discuss calculation validation. Calculation validation is an item that is usually checked by validation tools and highlighted by auditors when performing XBRL related engagements. The highlighted inconsistencies should be reviewed carefully to determine if they warrant correction.

This issue, probably more than any other, seems to instill immediate panic in filers. I think I get it. As accountants (a title that includes the word “count”) we are offended when something we are responsible for includes an issue referred to as “calculation error.” Our job often includes making sure that numbers line-up correctly without errors so the thought of this not happening does not settle well.

Do not immediately jump to conclusions that your XBRL exhibits were filed incorrectly. In many cases, the inconsistencies are a result of how XBRL calculation validation is performed for your organization’s segmented data, rather than what accountants would typically view as a calculation error. Also, it is common that restructuring or removing the relationships that result in these associated validation inconsistencies would violate the SEC’s requirements. Filers should be very careful when looking to “fix” or remove them.

Let me provide one of the most common examples we see with our clients that would result in an XBRL calculation validation inconsistency.

The organization’s Balance Sheet includes a line item of Total Current Assets that is composed of Cash, Accounts Receivables, Inventories, Prepaid Expenses, and Other Current Assets. As discussed in the last blog, a calculation relationship occurs when we have Total Current Assets as the parent of the hierarchy, and each component serves as a child. The SEC’s guidance requires a calculation relationship in this manner.

In the Segment Reporting note to the consolidated financial statements, a textual disclosure may be presented as follows “Our East Segment had $40 million of current assets which included $30 million of accounts receivable.”

When the XBRL calculation validation is performed, the validation tool will look at the East Segment data and try and add up the components that were reported to the total line item that was reported. In the above example, the validation will only find one value from the children elements, the Accounts Receivable of $30 million, and compare that to the Total Current Assets line item of the East Segment which was reported at $40 million. Since the values do not agree, the XBRL calculation validation will result in an inconsistency.

If you removed the calculation relationship that was included from the Balance Sheet to avoid this error, you would violate the SEC guidance that requires the relationship. If you add a value to the XBRL data that is not included in the HTML version of the filing to alleviate this issue, you would also violate the SEC’s requirements. Potentially, I guess a filer could choose to add the missing components to both their HTML and XBRL disclosures to address it, but I do not think these XBRL calculation inconsistencies should be an input in your organization’s decision’s about what to disclose or not. These disclosure decisions and effort are best informed by investor and creditor needs, US GAAP, etc. – not some goal of trying to achieve a “perfect” XBRL filing.

When I provide the above example to clients or their XBRL advisors, I think they get it. However, they are usually skeptical that these types of scenarios actually exist in their filing, or at least to the degree and number of calculation inconsistencies identified in their filing by the validation tool. When we look at details with the client, I find many of them shocked to see valid explanations.

Other common reporting disclosures that frequently result in calculation inconsistencies occur when entities report values for multiple classes of stock or when presenting an equity footnote that includes some of the components of equity in the footnote for periods other than those presented on the balance sheet.

I hope the above explanations will help the next time you get that immediate panic feeling when an advisor or validation tool alerts you to calculation inconsistencies in your filing. Notwithstanding the above explanations, sometimes calculation inconsistencies can be a result of improper calculation structure, incorrect negative values, or other inappropriate XBRL submission details. Some of these types of issues certainly can negatively impact the quality of your data so you may want to review the calculation inconsistencies in detail. Rivet’s DragonView product performs calculation validation and displays the results as shown in the following screenshot:

In my next blog, I will discuss units of measure.

Related blogs:

Part 1 – Your XBRL Filing Is Not Perfect »

Part 2 – Negative Values in XBRL Filings »

Part 3 – Decimals Attribute in XBRL Filings »

Part 4 – Calculation Relationships in XBRL Filings »

Part 5 – Calculation Validation in XBRL Filings »

Part 6 – Units of Measure in XBRL Filings »

In the last section of this blog series, I discussed the decimals attribute. In the next two blog sections, I will describe items related to calculations. In this section, I will discuss some limitations and considerations when creating calculation relationships in your SEC filing, and in the next section I will discuss calculation validation.

Identifying appropriate calculation relationships can be one of the more complex areas of XBRL submissions to the SEC, so it is no surprise that this is another area of focus by auditors. Since calculation relationships can be so complex, it is important to review comments made by auditors in this area very carefully to determine if the issues highlighted truly warrant correction.

I will go into detail about what you can do to review this area, but first, let’s describe why it is important. Calculation relationships can be valuable to data users of your XBRL filing. These relationships make explicit, for example, the component line items that total into your organization’s Operating Income. Accordingly, an XBRL data user could relatively easily query the Operating Income calculation relationships of Apple and Microsoft to understand each organization’s components of Operating Income. The SEC defines calculation relationships as:

“Additive relationships between numeric items expressed as parent-child hierarchies.”

By following the Operating Income analogy, the Operating Income line item would be the parent of the hierarchy, and the children would be income line items (usually credit items) as well as the operating expense line items (usually debit items). The credits + debits (i.e. opposite of credits) = some net credit or net debit that equals the Operating Income (Loss) for the period.

That doesn’t sound so hard, why is it so complex? The current specification accepted by the SEC for calculations is somewhat limited. First, the SEC’s guidance for XBRL filings specifically precludes filers from including a calculation relationship for items of different periodType (the SEC has appropriate technical reasons to limit this in the XBRL submission). This may not seem like a big limitation, but it pretty much means that all the rollforward calculations in your HTML filing cannot be expressed in your XBRL exhibits. For example, a disclosure like the screenshot below could not be included in the XBRL submission to the SEC because the Balance line items have an instant periodType and the line items for the activity during the period would have a duration periodType:

Another limitation of the calculation specification to the SEC is that if the element that represents the total is a credit balance type, then the components that are credits must be added together and never subtracted. This may be a good standard, but it actually impacts the required structure of many calculation relationships for a number of financial reporting disclosures. The most common is Long-Term Debt.

In the above screenshot from the HTML document, the current portion of debt is subtracted from Total debt to arrive at Long-term debt. Due to the XBRL requirements described above, this calculation cannot be expressed exactly as it is in the HTML filing. Instead, the XBRL calculation must be expressed as current portion of debt, plus Long-term debt, equals Total Debt. By creating the calculation relationship in this way, you adhere to the XBRL requirement that a total credit line item can only include the addition (never subtraction) of components that are credits. In addition to the above examples, there are even more complex scenarios and circumstances which may impact the appropriate calculation structure for submissions to the SEC. The calculation relationships in an indirect cash flow statement can be particularly complex due to the nature of Net Cash Provided by Operating Activities, for example, including Net Income as a source (a credit) and also noncash Depreciation expense as a source (a debit). If you would like to review calculation relationships in detail, Rivet’s Dragon View product provides a hierarchical display of the calculations relationships in each report.

In my next blog I will discuss calculation validation.

Related blogs:

Part 1 – Your XBRL Filing Is Not Perfect »

Part 2 – Negative Values in XBRL Filings »

Part 3 – Decimals Attribute in XBRL Filings »

Part 4 – Calculation Relationships in XBRL Filings »

Part 5 – Calculation Validation in XBRL Filings »

Part 6 – Units of Measure in XBRL Filings »

In the first section of this 5 part blog, I talked about the critical issue of negative values. While many negative value issues significantly reduce the quality of data, I mentioned that it is important to scrutinize auditor comments or validation exceptions because they do not always warrant correction. The same will be true for this section and the 3 remaining parts of this blog series.

The next common area of auditor concern to discuss is the decimals attribute. The decimals attribute in XBRL is used to convey the level of accuracy to which a fact is disclosed. In layperson’s terms, it is used to distinguish if an amount is presented, for example, “in millions” or “in thousands.”

In our observations, generally when auditors make comments about the decimals attribute, it is not often related to a major discrepancy, e.g. reporting your Balance Sheet amounts as “Exact” when it should have been reported as “Rounded to Millions.” Instead, generally when we see auditor remarks in this area, it is related to much finer distinctions. I will now provide some background on this before I move forward with explaining the process more in depth.

Since the decimals attribute may be new to many of you, below is a brief legend between the numeric value of the decimals attribute, and what it would mean to a data user.

XBRL Syntax	Meaning to a data user
decimals=”-6”	Rounded to Millions
decimals=”-3”	Rounded to Thousands
decimals=”2”	Rounded to Hundredths
decimals=”0”	Rounded to Whole Number
decimals=”INF”	Not Rounded, value is exact

Every numeric fact disclosed in your XBRL filing will include a separate value of the decimals attribute to indicate the level of accuracy that the fact is reported and it will use the form of the XBRL syntax displayed above.

If your Balance Sheet represents monetary amounts “in millions” in your HTML filing, then all the associated Balance Sheet amounts in your XBRL filing would each include “decimals=”-6”” with them.

But let’s look a little deeper at the decimals=”INF” (by the way, INF is short for – infinitely accurate) value that represents an exact value. Why is it important to represent an amount as Exact? Tagging a fact as “exact” can be very helpful in analysis. For example, let’s pretend I own a million shares of your stock (I wish). If you represent your quarterly dividend as 14 cents per share with a decimals attribute of “INF”, then I know I will get a dividend check in the mail for exactly $140,000. In contrast, your company may report EPS for the quarter of 18 cents per share with a decimal attribute of “2” (meaning rounded to the nearest cent – EPS would almost never be presented as an exact number). Since I know the amount is rounded to the nearest cent, I would know the value of EPS attributable to my million shares would be between $175,000 and $184,999. When performing analyses of XBRL data, these distinctions of accuracy may be important in understanding the data sensitivity of the findings and conclusions.

For this reason, many contractual amounts included in your filing should be represented with a decimal attribute of “INF.” Some common examples include Shares Authorized, Dividends Declared Per Share, Debt Face Amount, and Debt Stated Interest Rate.

In the majority of auditor comments we have observed around the decimals attribute, the auditors have not objected to issues of the above application – most filers appear to get those items right.

We see the most common auditor observations relating to disclosures that this distinction may be less clear. For example, the other day a client shared with us their auditor’s comment where the company reported something like Number of Stores Operated by Entity “Rounded to Whole Number” and the auditors suggested changing this to “INF” (i.e. exact) to reflect a more accurate decimals attribute. On first pass, the auditor comment may appear to warrant correction. A Number of Stores Operated by Entity disclosure of 355 might seem exact since you would not expect the number could be rounded down from 355.2 (because intuitively it would not make sense to have fractional stores). However, further examination may warrant that using “Rounded to Whole Number” is appropriate. This disclosure was presented for a period over time, (e.g. for the 12 months ended). Is it possible, or even likely, that some stores opened and closed during the 12 month period? If so, does the value represent gross stores operated during the period, the net, or some weighted average? For these concerns, which may not always be easily verified, it may be appropriate to represent this amount with “Rounded to Whole Number” rather than potentially reporting the value as “Exact,” when in fact the value may not be that precise.

Perhaps most importantly, how “perfect” do you need your filing to be? Considering finite reporting resources in your department, do you think it is important enough to make this accuracy distinction at the cost of reviewing other areas of your XBRL filing such as element selections or perhaps incorrect sign issues discussed in Part 1? Even as the SEC’s limited liability provisions expire, would you assess a high compliance or litigation risk for presenting your Number of Stores as “Rounded to Whole Number” instead of “Exact”? Adding this type of perspective to your XBRL review may not be something the auditors are able to provide because of applicable professional standards. I think it is very important because you will want to dedicate your review effort appropriately.

However, this is not to minimize the issue of the decimals attribute completely. If your Net Income was reported as $15 million, but in the XBRL data it was incorrectly reported with “INF” to represent it as “exact,” this could significantly impact the quality of your data. Data users would interpret this amount as $15,000,000 and if they found out that the organization’s actual Net Income was $14,587,000 and rounded up to $15 million perhaps they would argue that your company’s error in the XBRL data impacted their investment decisions that were based on a Net Income level of $15,000,000 (without rounding) and could result in potential litigation risk. While this type of error has appeared to be pretty rare, you may want to implement extra review procedures for certain key disclosures such as Net Income to minimize risks to an acceptable level.

No matter what level you choose to review your XBRL data, we make our Crossfire Reviewers Guide as easy as possible to review this information. You can review tags individually, or perform custom Filter reports to focus on specified areas of risk:

If you are not using Crossfire to prepare and review your XBRL data, this information can also be easily reviewed from the Data View display in our DragonView product:

My next blog will discuss calculation relationships in XBRL filings.

Related blogs:

Part 1 – Your XBRL Filing Is Not Perfect »

Part 2 – Negative Values in XBRL Filings »

Part 3 – Decimals Attribute in XBRL Filings »

Part 4 – Calculation Relationships in XBRL Filings »

Part 5 – Calculation Validation in XBRL Filings »

Part 6 – Units of Measure in XBRL Filings »

Through our experience with providing over 2,000 XBRL Exhibits to SEC filers, we have worked with a number of audit firms (primarily the Big 4) that assist clients in the review of their XBRL Exhibits. If you have been following the SEC’s Staff Observations, it should be no surprise that one of the common areas of auditor focus is on negative values.  This is often an area of primary focus by the SEC in its published guidance, as well as reports and presentations throughout the XBRL marketplace.  This area is very important because issues of incorrect sign have an extremely significant impact on the quality of data.

Are you okay with reporting an expense as a credit? I guess if you are Bernie Madoff you might not care, but the thought of misreporting expenses as credits sends a shiver down all good accountants’ spines.  An issue of incorrect sign usually means that a Debit was incorrectly reported as a Credit, or vice versa.  Because these issues have so much impact, it is no wonder they are spoken about so much and represent a critical area of focus.

If you need more background on the issue, look no further than the SEC’s June 15, 2011 Staff Observations.

SEC excerpt:  “While many times in the HTML filing numbers are presented as negative, they should almost always be tagged as positive numbers in the XBRL submission.”

In this screenshot, the interest expense values are presented as negative in the HTML filing.  If these values are also reported in the underlying XBRL data as negative, a data user will likely interpret your interest expense as interest income.

More from the SEC:

”Checking the validity of negative values cannot be done from the rendered copy of the XBRL financial statements.  One of the most common errors filers make is to incorrectly enter an amount with a negative value.”

If this information cannot be reviewed from the rendered copy of the XBRL financial statements, how are you supposed to review it?

There are a lot of different approaches a reviewer can perform to assess reporting accuracy in your XBRL files.  The observation by the SEC is that negative numbers have a higher risk of being incorrect.  What do accountants and auditors typically do when addressing areas of higher risk?  We increase testing, and one potential procedure in this case might be to perform a detailed review of all negative amounts reported in your XBRL data.

In Crossfire’s Reviewers Guide, we try to make this is as simple as possible.  You create the filter below and Crossfire will interactively take you through your filing to any negative values that are being reported in the underlying XBRL data:

For each value, you can make a determination as to the appropriateness and record a comment which will be available to other users.  In this example, the negative value appears to be appropriate.

If you are not currently preparing your XBRL filing through Crossfire, you can also use our DragonView tool to provide a review report.

This report can be exported to Excel, and then you can add your review comments and save it with your other XBRL documentation for the filing period.

As you can tell, the issue of negative values can severely impact the quality of your data.  These items need to be reviewed carefully, so if an auditor or an automated validation tool raises an incorrect sign issue, it does not necessarily mean it is an error.  A concept I was probably first forced to grapple with during preparation for the CPA exam, exceptions to the exception, is also very relevant here.  While a negative XBRL fact for Assets might be flagged by an auditor and expected to be incorrect, the below screenshot displays an exception to the exception – careful review indicates this negative value for Assets is appropriate.  With a bit of XBRL education and the right tools, your organization can implement review procedures to minimize the risk of issues in this critical area.

My next blog will discuss the decimals attribute in XBRL filings.

Related blogs:

Part 1 – Your XBRL Filing Is Not Perfect »

Part 2 – Negative Values in XBRL Filings »

Part 3 – Decimals Attribute in XBRL Filings »

Part 4 – Calculation Relationships in XBRL Filings »

Part 5 – Calculation Validation in XBRL Filings »

Part 6 – Units of Measure in XBRL Filings »

As more companies start to abide by the SEC’s XBRL mandate, this process has forced everyone to learn from their mistakes and evolve with the changes it has produced. Not only software vendors like us, but also the SEC, FASB, and XBRL US have made mistakes; software vendors had to learn to create complex validation rules to prevent technical syntax errors flagged by the EDGAR system while the FASB learned it needed to improve definitions on some standard elements. These changes have allowed the market to mature quite a bit, but as XBRL continues to grow and fulfill its role as the global language of finance, we all still have more learning ahead of us.

Your XBRL filing is not perfect! When you really think about it, there is no real definition of what a “perfect” XBRL filing is, for example, we are pretty certain that one Big 4 accounting firm’s opinion of a perfect XBRL filing would be different than another’s. I know, I know, I am an accountant too and the very core of our nature desires “perfect,” neatly ticked and tied, XBRL that is reconciled one-for-one right in line with the source information. That part of our nature is the reason we signed up for those accounting classes in college in the first place. But for many of us, our first job out of college taught us that this is not the way accounting works in the “real world.” We had to learn to start using terms like “waive further review” or “to a material degree” to get more comfortable with accounting in the real world, a less than perfect place. Well, preparing and reviewing XBRL is not really any different. It’s important to identify and understand your organization’s risk tolerance levels with respect to XBRL data to ensure your review processes and controls are consistent within the scope of those acceptable limits.

The Scare. Many of you experience what I call “The Scare” when your auditors (or audit firm competition) drops on your desk something related to XBRL Quality Issues. It might be an AUP (Agreed-Upon Procedures) report performed at your direction, or it could be a marketing document that is not even necessarily directed at your particular organization’s filing. In any case, these documents discuss all the potential errors and poor quality in the XBRL filing, and it can be real scary. The error patterns described are usually insidious, invisible to many of the review procedures and reports you focus on.

While The Scare may hit upon some of those panic nerves, try and remain calm.

Not all errors are created equal. When a Big 4 accounting firm provides a report with exceptions, they are often making findings with respect to performing a set of procedures. Many times the auditors themselves may be precluded from providing you advisory services which would help you evaluate the significance or impact of these findings to the users of your XBRL data. These reports often communicate “your XBRL files are not perfect” but because of auditor independence rules and professional standards pursuant to the relationship with your organization, they may not really be able to help you put these issues in perspective. Some issues (for example, incorrect negative values) may significantly impact how data users interpret your XBRL submission. Other items however, are often identified by auditors (for example, calculation inconsistencies) and may be a necessary consequence of appropriately complying with the SEC’s requirements. The remaining issues identified may relate to relatively unimportant convention standards that could have little or no impact to users of the data. We have even observed some auditor observations that were technically incorrect as the auditors have also not been exempt from “learning” the technical guidance and requirements of XBRL submissions to the SEC.

This is not to say that auditor involvement is not helpful – it is. Bringing an additional set of eyes to your XBRL data and associated processes may provide valuable feedback with respect to any potential reporting errors in your filing or more importantly, potential gaps in your organization’s review processes.

In the end, “perfect” XBRL files are really your own organization’s decision, depending on the depth and breadth of the review procedures chosen. Like a good accountant recently told me, creating high quality XBRL is really about the process. Perhaps the most effective solution in addressing XBRL related risks is to adopt an integrated reporting solution. Systemic controls in an integrated system can generally be less time consuming and more effective than manual reviews and controls.

No matter what decisions your organization makes with respect to your reporting and review processes, I hope the next 5 parts of this series will help you make insightful decisions and better understand your XBRL exhibits. Each part of my 5 part blog series will focus on a common area that we have observed the firms focus upon. In each discussion, I aim to provide a high level description of the issue, the potential impact of related errors on the filing, and some of the Rivet review filters or reports available to identify the issues. Next week will focus on negative values.

Related blogs:

Part 1 – Your XBRL Filing Is Not Perfect »

Part 2 – Negative Values in XBRL Filings »

Part 3 – Decimals Attribute in XBRL Filings »

Part 4 – Calculation Relationships in XBRL Filings »

Part 5 – Calculation Validation in XBRL Filings »

Part 6 – Units of Measure in XBRL Filings »

Related Links:
Blog: Will the SEC react to the demands of apprehensive XBRL filers? (Patrick Quinlan) »
Blog: Deep Dive Reviewing (Stewart McKie) »