The State of FinTech

The recent travails of Lending Club have shone a not-so-flattering light on FinTech startups. On the surface, the finance industry replete with large slow-to-innovate institutions appears ripe for disruption. However, the performance of the recently public FinTech companies shows that finance make not be as easy a target for disruption as FinTech companies have made out.

What is FinTech?

FinTech startups attempt to take a single business line in the finance industry and apply new technology and business practices. In general there are four primary business lines startups have focused on:

  • Wealth Management (Betterment, Wealthfront)
  • Transfers (Transferwise)
  • Payments (Square, Stripe)
  • Lending (Lending Club, OnDeck)

In this article I will focus on the the lending space which has seen the most turmoil in recent months. 2015 saw the debut of two lending companies on the public markets — namely Lending Club and OnDeck. Lending Club is a marketplace for personal small loans whereby the loans are on-sold to investors. OnDeck, by contrast, focuses on small businesses and utilizes its own balance sheet to fund the loans (although it also runs a small marketplace) and so more closely resembles a traditional bank.

The core proposition by the lending startups is that banks, who typically prefer loans under $15k to be done via credit card debt, have served the small loans market poorly. Furthermore, risk analysis can be done more efficiently and accurately using algorithms.

The IPOs for both Lending Club and OnDeck have proved disastrous with both Lending Club and OnDeck’s stock down by 80% and so slammed shut the door for FinTech IPOs in the short to medium term. Several categories of risk specific to FinTech startups have become apparent:

Funding Sources

FinTech lending companies are heavily dependent on consistent and stable sources of funding to back their loans (marketplaces such as Lending Club require investors to purchase the loans whereas on-balance sheet lenders like OnDeck require banks to finance their lending). The market turmoil of 2015 and 2016 has clearly demonstrated that these sources of funds are highly unpredictable — Lending Club is now having to warehouse on its balance sheet as it not able to find investors to purchase sufficient quantities of its loans. Likewise OnDeck which had previously planned to offload 40% of its loans was only able to offload 15%.

Thus, despite efforts to broaden their funding base, both OnDeck and Lending Club are having to rely on traditional institutional (mainly bank) funding to fund their loans, the withdrawal of these lines of credit could pose an existential risk for the companies.

Reputational Risk

Tech startups often endure several public setbacks such as security breaches or privacy violations. These are often swiftly overcome and forgotten and the company progresses. Not so for finance companies where infractions can lead to a loss of confidence and a withdrawal of funding. Lending Club’s changing of the dates of $3m of loans (out of a total of ~$3bn loans originated) as well as the CEO’s undisclosed shareholding in a related party have proved so serious that the firm has not only removed the CEO but cannot provide earnings guidance as there is so much uncertainty regarding the fallout.

Regulation

FinTech companies are currently more lightly regulated than the banks who they are competing with. This is likely to change as regulators turn their attention to ‘shadow banking’ and in loan marketplaces where individual investors are investing in loans (note that FinTech lenders are targeting individual investors as more stable source of funding)

Credit Quality

FinTech lending companies trumpet the sophistication of their risk analysis technology, however, this is essentially a black box and it is impossible for investors to evaluate until the company has gone through a complete credit cycle as credit risk assessment can be flattered by an overall macro environment strong credit (as is the case in 2016, demonstrated by the below chart).

 1-k2ggBfYliyNZcpTcuD8F9Q
US Corporate Bankruptcies 2006–2016

Traditional Startup Metrics

All this naturally leads to how should FinTech companies be valued. There’s been considerable debate on the subject of FinTech company valuation — should they be valued as typical finance companies or tech companies? The issue has a massive impact on valuations since tech companies tend to be valued on a multiple of revenue (typically around 4x for Saas companies), whereas finance companies tend to be valued using a multiple of their net assets which usually gives a far lower valuation.

Needless to say FinTech companies argue vociferously that they are tech companies and should be valued as such. Yet the core reasons tech companies are valued on multiples of revenues don’t apply to FinTech companies:

  • Tech company revenues are relatively stable (it is usually the level of growth which causes uncertainty). This is because there is usually some degree of lock-in for tech companies’ customers — with social media companies it is the network of friends/colleagues, for Saas companies it is the customer’s investment in time to adapt to using the product and the difficultly in migrating to a rival product. None of this applies to FinTech lending companies whose customers can easily move to alternative platforms.
  • Tech company margins tend to be predictable and manageable. The costs of delivering a tech product or service do not swing wildly and so gross margins can be forecast and managed. Not so for FinTech lending companies who are at the mercy of the vicissitudes of the economy which determines interest rates, demand for loans and default rates all of which have a direct impact on gross margins.

Despite all of this, the market is still focused on revenue as the primary driver of valuation although this is likely to change as the companies mature and the market’s approach to valuing tech companies evolves.

Profitability Measures for Tech Companies

With the tech funding market’s shift in focus from revenue growth to profitability as come a lot of confusion on which measure of profitability is a suitable benchmark for tech companies.

Gross Profit

Revenue less costs directly associated with delivering that product/service. The costs are relatively straightforward for physical goods (ie the cost of originally purchasing the good and then delivering it to the customer) this is a little less clear for tech companies providing a service. The cost directly associated with the sale are then the allocated cost of the servers and infrastructure as well as the full cost of support staff.
Why its Important: Gross Profit is the single most important profitability measure for tech companies and gross profit margins (gross profit / revenue) should typically be above 50% for an eCommerce company and above 60% for Saas or digital media companies. Low gross margins businesses may still be viable but they struggle to grow at the rates that VC’s or markets demand as they do not have enough residual margin to pay for a large sales effort.

Contribution Margin

This is not found on an Income Statement and should be treated with caution. The contribution margin is revenue less variable costs divided by revenue, although the precise definition varies from company to company since there is no agreed upon standard. The only difference with gross profit margin is that contribution margin excludes fixed costs and so it will always be higher than gross margin. For tech companies this will typically be the depreciation of the hardware (usually servers) which delivers the service. Depreciation is essentially the apportioned cost of hardware required to deliver the service and ignoring it gives a distorted view of profitability.

Operating Profit

Gross Profit less expensing incurred in normal business operations such as sales, marketing and admin expenses. Few tech companies under 10 years of age generate any meaningful operating profits. Marketplaces and digital media companies tend to run at around operating profit break-even. Saas companies usually run around -15% operating profit margins since Saas revenues don’t reflect the lifetime values of their customers.

Net Profit

Operating profit less non-operating expenses sure as interest payments, one-off charges and tax.
Typically for tech companies this is similar to operating profit.

Cash Flow

All profits should eventually manifest as cashflow (that there is a different at all is primarily due to accounts being prepared under the accruals concept which allows companies to recognize revenues when they are ‘earned’ but not paid).
The two most useful measures of cash flow are Operating Cash Flow which is the cash generated from ongoing business operations and Free Cash Flow which is Operating Cash Flow plus capital expenditure. For tech companies Free Cash Flow is the more relevant measure as capital expenditure (primary on hardware such as servers) should usually be considered necessary ongoing expenditure.

High negative free cash flow relative to revenues or to cash balance are a warning signal and cannot be sustained for long periods.

It should be noted that many public tech companies (notably Twitter) operate at cash flow break-even but record large net profit loses. The core reason for this is the accounting requirement to expense employee stock option grants which reduces profits but has no impact on cash flow since option grants involve no cash outflow.

EBITDA/EBIT/Adjusted Earnings

These are all ad-hoc measures created by companies which claim to give a truer picture of their profitability and should all be treated with extreme caution. There can be significant insight gained from adjusting GAAP accounting earnings — in Saas businesses for example revenue could expanded to account for some of the customer’s lifetime value. However, this should be done conservatively and consistently applied across different companies.
Relying on companies’ own measures of adjusted earnings is fraught with danger as there is no common definition for the measures and companies often cherry-pick which items to exclude to flatter their earnings.

Tech Valuation Trends to Watch in 2016

In a previous article I discussed the declining importance of revenue growth in setting valuations, the question that now needs to be asked is what factors are now driving valuations and what the remainder of 2016 holds for tech valuations.

A conundrum in understanding the recent selloff in stocks (and the associated compression in tech valuations) is how indiscriminate the mark down valuations was. Aside from the reduced premium for high growth companies little attention appears to have been paid to companies’ internal fundamentals (such as profit margins or cash flow). As such, regardless of what measure of profitability is used there remains no correlation between valuation and profitability for Saas companies (or for Social Media/Digital Media companies).

I prefer to view the recent market repricing as the first stage in a two stage process. In the first stage (which appears to have been completed) all valuations are written down in a sharp market adjustment with little regard being paid to the individual companies’ fundamentals.

The second stage of the repricing is a more gradual reassessment of the merits of each company. So the key question is what metrics will the market focus on in future for valuing tech (and more specifically Saas) companies.

Profitability

The end goal of any business is (or should be!) to generate profit. There are two primary measures of profitability to focus on — gross profit (revenue less costs directly tied to producing the good/service) and net profit (gross profit less other costs such as marketing or R&D).

Gross profit margin is sometimes fashionably referred to a ‘unit economics’ as is the first measure of profitability to assess — after all if a firm cannot even sell a product for more than its cost its prospects are bleak. Recently, there has been extensive discussion on incorporating ‘unit economics’ into private market valuations and expect for this to be mirrored in the public markets. Thus in the short to medium term look for an increased correlation between valuations and gross profit.

Net profits tend to be a long time coming for tech companies and especially so for Saas companies (as they cannot recognize the full value of new customer in their revenue figures). Seeing a correlation between valuation and net profit for tech companies is still a long way off.

Cash Flow

Cash is the fuel that all companies run on and so a negative cash flow can only be sustained for so long. Companies that run persistent free cash flow deficits are likely to be heavily punished by the markets. There is some evidence that this is already happening, Box has seen its value cut in half since its IPO despite healthy gross profit margins of 70% and growing revenue 10% per quarter. Box’s free cash flow to revenue ratio is -0.47, meaning that for every dollar of revenue it looses 50 cents in cash. To compound this, Box can only sustain this level of negative free cash flow for less than 18 months before it will need a cash infusion.

Efficiency

The major impediment in converting revenue into profit is operational efficiency — ie what levels of costs relative to revenue does it take to maintain the business in its current state. Two useful benchmarks of operational efficiency are revenue per employee and Sales/Marketing/Admin expenses to revenue.

If cash flow and profits are to be a factor in valuation it therefore follows that measures of operational efficiency will affect valuation.

‘Legacy Tech’ Benchmarks

A notable feature in the early 2016 tech stock selloff was the resilience of legacy tech companies (ie mature tech companies whose growth has plateaued and are generating profits such as Oracle, Microsoft, IBM). Since 2014 the Enterprise Value/Revenue ratio of legacy tech companies has steadily increased whilst that of Saas companies more than halved.

ScreenHunter_29 May. 17 12.30

Legacy Tech and Saas

The above graph shows that Saas valuations are now, on average, very similar to those of legacy tech companies. However, whilst the overall EV/Revenue multiples are now similar, legacy tech valuations are much more nuanced and profitability, cash flow, and operational efficiency are all correlated with valuation ratios. We can therefore reasonably expect that as Saas companies mature and the market turmoil settles that valuations of Saas company metrics should start to converge with those of legacy tech shown below:

Median Legacy Tech Company Valuation Benchmarks

  • Gross Profit Margin : 63%
  • Net Profit Margin : 13%
  • Free Cash Flow/Revenue : 24%
  • Revenue Per Employee : $340,000

The Declining Importance of Revenue Growth

Originally posted on PublicTechWatch and Medium.

To recap the first post on the Great Compression in Tech Valuations there are two related trends in EV/Revenue for Saas companies over the past three years – the overall decline in valuations (ie EV/Revenue ratios) and the clustering of valuations around the average (so it is increasingly unusual to be able to achieve a valuation far higher than the average).

These two trends are actually closely related with the driving force being the premium the market has placed on high revenue growth companies.

The market used to put a very high premium on Saas companies which were able to achieve high levels of revenue growth (ie greater than ~10% per quarter). This is best examined by looking at regressions of Revenue Growth vs EV/Revenue since March 2013 (a regression will show the strength of the relationship between Revenue Growth and EV/Revenue , with the ‘slope’ of the regression being the change in EV/Revenue per unit of change in Revenue Growth).

The below graph is the monthly slope of the regression for EV/Revenue vs Revenue Growth.

Note in the graph the slope units are in 1/100th of a percentage point so a slope of 100 would mean each 1% increase in Revenue Growth results in an increase of 1 unit the EV/Revenue ratio.

At its peak in September 2013 each percentage point increase in quarterly revenue growth would be rewarded with an increase of 1.4 in the EV/Revenue ratio – thus in Sept 2013 LogMeIn with revenue growth of 5% had a EV/Revenue ratio of 4, whereas Tableau Soft with growth of 15% had a EV/Revenue of 20.

By March 2016 the slope was down to 0.36 so each percentage point of growth is worth a mere 0.36 in the EV/Revenue ratio (for example MobileIron which is growing revenues at 4% has a EV/Rev ratio of 1.7 whereas the faster growing New Relic which is growing at 13% and has a EV/Rev ratio of 6.1).

The decline in the premium for high-growth companies has primarily affected the top quartile of fast growing companies. The below graph shows Saas EV/Revenue ratios divided into revenue growth quartiles with the highest growth companies attracting the highest EV/Revenue ratios.

Note the greater decline in the valuations of the fastest growing quartile of companies which converged with the slower growth companies, reducing the valuation differential and dragging down the overall average.

Why Did the Market Fall Out of Love with High-Growth Companies?

As explained in detail by Joseph Floyd, Saas valuation compression is simply a reversion to the mean after valuations diverged from other tech companies in 2012. But was the cause of the divergence and subsequent reversion? As I see it there are three possible explanations for this – although it is difficult to assess the validity of any of these.

  1. The number of Saas public companies for investors to invest in has grown from approximately 10 in 2012 to 40 in 2016 (depending on your definition of Saas of course..). Investors looking for exposure to Saas have more options for companies to invest in.
  2. General market risk appetite has declined. Since mid-2015 the S&P High-Beta index has under performed the broader index as investors rotate into less risky companies. Saas companies which typically are young and have minimal profits would certainly be considered as high-beta or risky assets.
  3. Failed promises of public Saas companies. Public Saas companies have in general failed to deliver on profits and in several cases such as LinkedIn the growth trajectory has leveled off earlier than expected.

It is important to note that this is a big reason that private companies can have higher multiples than their public counterparts as they are very often growing faster and so should have a higher multiple.

The Great Compression in Tech Valuations

Originally posted on PublicTechWatch and Medium.

In this series of posts I will examine the compression in tech valuations (as measured by the Enterprise Value/Revenue ratio).In this first post I will take a look at what exactly happened and look a little beneath the surface at some of the underlying trends.

In the second post I will focus on the causes of the upheaval in valuations and finally in the third post I will look to the future and highlight some of the possible and probable valuation trends for the remainder of 2016.

Measuring Valuations for Tech Companies

The received wisdom for tech company valuations, especially young fast-growing companies, is that they should be valued on a multiple of revenue. There are two primary reasons for this, firstly fast growing tech firms rarely have any significant profits (and so ratios such as Price/Earnings or multiples of Net Income will not be useful). Secondly, revenue is a relatively ‘clean’ metric as it is less prone to manipulation and earnings management than figures lower down the Income statement such as Net Income or calculated metrics such as EBITDA.

I will examine other valuations methods and metrics in a future article but for now the primary metric will be the Enterprise Value to Revenue ratio. Enterprise Value (EV) takes market capitalization as its starting point and then adjusts this for the firm’s debt and cash balances to get a more comprehensive valuation (for a more detailed explanation, please refer to Damodaran’s overview of valuation methods).

How Have Valuations Changed?

The compression in the Enterprise Value/Revenue multiple has been extensively documented but just for completeness note the below graph with shows the median EV/Revenue ratio for Saas companies declining since 2013 from a high of 11 in early 2014 to a low of 4 in February 2016.


EV/Revenue Mulitple For Saas Companies

Despite the recent proliferation of blog posts about the ‘Great Compression’, the trend is the trend is not new – the peak in valuations was in early 2014. Most of the commentary on this compression in valuation ratios has focused on Saas companies, so it is worth looking at other tech sectors. The below graph shows the ratios for Digital Media (Google, WebMD, Yahoo, Pandora), eCommerce, Marketplaces and Legacy Tech (comprising mature tech companies such as Microsoft, Oracle and Computer Associates).

EV/Revenue Multiples for Tech Sectors

There are a few interesting things to note here. Firstly, Legacy Tech has been immune to the trend of valuation compression with its valuation ratio actually increasing from 2.2 in early 2013 to 3.4 in March 2016. Digital Media, eCommerce and Marketplaces ratios have all peaked from Dec 2013 to Dec 2014 and suffered declines since. eCommerce companies have the lowest valuations with the median EV/Revenue ratio at just 1.4.

Before examining the reasons for this compression we can take a closer look at the individual valuations within the averages, in particular the range of the valuations. In March 2013 there was a wide spread of EV/Revenue valuation ratios for Saas companies ranging from 2.75 (for LifeLock) to 31 (for Workday). By March 2016 the range was from 1 (Bazaarvoice) to 11 (Workday).

This can be better illustrated by using fitted normal distributions for different time periods (these distribution curves show frequency for different values of EV/Revenue). The graph below shows the distributions on March each year starting 2013. The graphs graphically illustrate the decline in the average value for Saas EV/Revenue multiples (note that the average is the peak of each graph which has consistently shifted lower – it to the left) more notably the distributions are more compact with March 2016 showing most companies clustered around the mean EV/Revenue of 4 versus the very spread out March 2013 distribution.

 

TL:DR;

  • EV/Revenue ratios for Saas, Digital Media and eCommerce companies hit their peaks in 2014 and have been declined since. Legacy Tech companies (such as Oracles) have seen the valuations ratios steadily increase (albeit from a low base).
  • eCommerce companies continue to attract the lowest valuation ratios.
  • Individual company valuations are now more tightly clustered around the averages with far fewer outliers.

In the next post I will examine the causes of the compression in valuations.

Revenue Recognition For Technology Firms

When and how much revenue to recognise in a firm’s accounts is one of the most contentious and important issues in financial accounting. The issue is especially acute for tech firms since early-stage tech firms may not yet have reached profitability, thus revenue and revenue growth will be key financial metrics. In addition, technology firms often sell intangible products and services which can be more difficult to determine a revenue for.

The first thing to note is that there is no clear-cut consensus on revenue recognition, there are only a set of broad principles which need to be applied. The overarching rule is that revenue should be recognised in a firm’s accounts only when a valid order has been received, there is a strong likelihood of receiving payment and the product/service has been delivered.

The relevance of a valid order is relatively simple – a firm must have received a product/service order if it is to consider the revenue earned. Firms will sometimes ship products to potential customers in anticipation of an order, if the potential customer does not wish to keep the product they can return it at no cost. In this scenario, shipping the product is done without a purchase order and there has clearly been no valid sale and no revenue should be recognised. In the digital world, a close relation to shipping in advance of an order this would be free trials of an online service which entail no obligations from the user and no revenue should be booked for these.

To recognise a sale as revenue the full payment does not need to be received but an assessment must be made about the likelihood of receiving the payment. If it is likely that a payment will be made then the firm may book the sale as revenue. For example, an app purchase on the Apple App Store can be booked as revenue immediately despite the fact the the funds will not be received for one month.

The delivery of the product/service is usually the area when most confusion and disagreement arises. If there is a physical product then it could be considered as delivered when it is delivered to the customer or when it is shipped (either dispatched from the firm’s warehouses or, more conservatively, when received by the customer).

 


Software

Delivery of digital goods is more difficult to define. For a software application, the customer must have taken dilvery of the application and accepted it. However, for more digital products such as software applications, the product itself is not the sole deliverable. Typically, there is support, training and upgrades included with the purchase. In such circumstances the firm must make an assessment of the fair market value for each of the bundled services and only recognise the portion of income associated with each element when it has been fully delivered.

Consider, for example, Microsoft’s accounting policy :

Microsoft’s earned revenue reflects the recognition of the fair value of these elements [ie the individual components of the order such as upgrades and technical support] over the product’s life-cycle.

The payment received for the product which has not yet been recognised will be held on the Balance Sheet under ‘Deferred Revenue’. For example, if a software firm sells a software application including one upgrade in a year’s time for $100 and it is determined that the value of the upgrade is $20 then the firm will show the $100 in its Bank/Cash on the Balance and $80 in Revenue in the Income Statement, the balance of $20 will be in Deferred Revenue on the Balance Sheet. In one year’s time when the firm’s obligation to deliver the upgrade has been fulfilled then the $20 in Deferred Revenue will be removed and $20 will be added to Revenue.

Note that this type of accounting is appropriate for vendors selling pre-built software applications. For vendors selling software development services such as third-party app developers, a contract method is appropriate whereby the revenue is recognised on a percentage-of-completion basis.

 


Digital Goods

Digital goods represent an accounting challenge as there is often no real-world analogue. Deloitte, although not a regulatory body are the auditors for many vendors of digital goods such as Zynga and issued a detailed guideline on digital goods accounting. In general, an assessment should be made on the period over which the good will be used. Revenue will then be recognised over that lifetime. A key issue with this is that the firm itself is responsible for estimating useful lifetimes and this estimate is difficult to test or evaluate since the data used will be internal to the firm and not publicly available. Subsequent changes in these estimates will directly impact the firm’s Revenue and earnings, for example Zynga has repeatedly reduced the estimate of the months a player will play its online games, this in turn reduces the lifetime of the digital goods the player purchased and essentially accelerated the recognition of revenue.

 


Exchanges and Marketplaces

A sale of a $30 book by Amazon will create $30 of revenue for Amazon, whereas a $30 book sale by eBay will only create approximately $1.5 of revenue for eBay*. The difference is that Amazon is consider the principal in the transaction whereas eBay is an agent.

The seller is considered the principal if it takes ownership of the product, establishes the sale price, assumes the risk of collecting payment from the customer and processes. The principal can recognise the full sales amount as revenue. Otherwise the firm is considered an agent in the transaction and may  only recognise the commission or agency fee for the sale.

For this reason Groupon was required to restate its revenues in its financial accounts. Groupon’s direct sales business offers goods and services at substantial discounts, orders placed on its website are routed to third-party vendors who are then responsible for dispatching the goods and handling returns. Groupon initially booked the entire sale value as revenue but was forced to restate this and only recognise its commission for each sale since it did not take ownership of the products prior to sale.

 


Returns and Cancellations

An important issue to consider for both physical goods and for services, is the rights of return/cancellation. If there is a right of return or cancellation then revenue can still be recognised provide the sale price is fixed, the buyer is still responsible to pay in the event of theft or destruction of the product and most importantly that the returns can be estimated. Thus the firm should have some history of returns and estimate a percentage of returns, this percentage should then be used a provision on the Income Statement (thus the full amount of the sales would be recognised as revenue and a provision for returns then deducted as an expense further down the Income Statement).

As always, there is a potential issue when a firm makes estimate using internal non-public data (in this case returns/cancellation rates). The provisions are frequently insufficient or can even be used to smooth earnings over time – largers than necessary provisions can be make during good periods and subsequently reversed during lean periods.

 


*This assumes a 1.5% total fee charged by eBay and that the Amazon purchase was from Amazon directly not a third-party on the Amazon Marketplace

Developing Financial Applications using XBRL

This article was originally published on CoreEarnings.com .

 

XBRL (eXtensible Business Reporting Language) is a data format for company financial reporting which can be easily consumed by software applications. The ‘Language’ in the name is actually a misnomer, XBRL is simply a data format as opposed to a computer language capable of performing operations. XBRL is a variant of the XML format which ‘marks-up’ data in a tag based syntax which is human readable. For example, to report Revenues the below code could be used :

<us-gaap:Revenues> 1500000 </us-gaap:Revenues>

This is clearly a simple format and for this reason XML based formats have become popular across a wide range of applications, since Office 2007 both Microsoft Word and Microsoft Excel use XML based formats (.docx and .xlsx respectively).

However, despite the promise of an easily consumable format for financial reporting data, XBRL is deeply flawed and has several major issues.

Issues with XML

XML is very useful for representing basic data structures, however as the complexity of the data structure grows the XML file(s) becomes extremely large and unwieldy. A set of company financial reports is a large and heavily structured set of data and so the XBRL files to represent them is very large. For a single quarterly financial report there will typically be at least six interlinked documents which will in total be about five times the size of the PDF.

XML has never been a performant data format, even for simple data structures, however it becomes incredibly sluggish for heavily structured data. To read and parse and single XBRL document took a dual-processor server between 50 to 80 seconds. There are a multitude of optimisations which could be applied but none are going to be sufficient to enable scaling and compete with database access times which are measured in milliseconds.

Thus, for any serious financial analysis we will need to develop a database schema and first read the XBRL document into the database which will then be the source of all analysis queries.

The XBRL Spec

Many of the elements for the XBRL specification were directly ported from the regulatory reporting requirements. The reporting requirements are sufficient for human analysis of financial reports but perform very poorly when translated into a data format to be consumed by software applications.

When reading financial reports it is very obvious which figures relate to the current reporting period. However to determine this for an XBRL document is not nearly so easy. For any given line item such as Revenue there are numerous Revenue items which relate to various periods and business segments, only one of these elements relates to the firm’s current Revenue for the actual period and determining which is error-prone. For starters, XBRL does not define the start and end dates for the current period and some companies use non-standard dates (for example Apple ends its reporting periods not on the last day of the period but the last business day). Thus to extract the actual reporting elements related to the current period some relatively convoluted (and hence error-prone) code logic is required.

In financial reports a zero balance is often not required to be reported. This works fine when reading reports but for a data format it is not very robust. For example, there is no debt on Apple’s Balance Sheet so the Debt elements are simply not included in the XBRL document. If we read the data into an application and attempt to calculate a metric which uses debt as an input an error will be thrown since the Debt element is simply not found as opposed to being found and having a zero balance. Thus, a zero balance will need to be programatically substituted when no element is found but this is definitely not robust (for example, we would like to know if an element could not be read properly for the XBRL doc and so was excluded for this reason).

A major omission from the XBRL spec is non-financial data which is often crucial for an analyst. For example, Apple includes unit sales (eg number of iPhone sales) in its reports but not in it XBRL filings.

XBRL Taxonomies

The above issues pale into insignificance when compared with the minefield of XBRL taxonomies.

The XBRL taxonomy is basically a template for the tagging and structuring various items which comprise a financial report.

XBRL allows firms a lot of latitude in selecting and even creating taxonomies, as well as changing taxonomies between reporting periods. Taking Apple again as an example, up until 2010 it reported its Fixed Assets using the XBRL tag aaplPropertyPlantAndEquipmentAndCapitalizedSoftwareNet , from 2011 it changed to using us-gaapPropertyPlantAndEquipmentGross. There was no notification of the change or mapping information so software parsing the two documents would not be able to associate the items as being the same balance for different periods.
The differences between XBRL documents of different companies is even greater, making financial comparisons between companies almost impossible.

The above issues (and especially the taxonomy issue) means that the manual intervention is almost always necessary original promise of XBRL to allow fully automated data analysis still unfulfilled.

What is ‘Cash’ on the Balance Sheet?

Cash on hand and cash flow are key indicators of financial health for any company, especially for young companies which are vulnerable to cash shortages. Although it would seem to be a straight-forward balance to assess and interpret, the cash balance is frequently misinterpreted and manipulated.

 

Cash Definition

The cash balance reported on the Balance Sheet is the cash in the bank adjusted for payments and receipts that have not yet cleared. Therefore, the cash balance on the bank statement will have cheques written by the firm but not yet cleared deducted and cheques received but not yet cleared added to the balance.

Cash Equivalents are frequently added to Cash on the Balance Sheet. Cash Equivalents are money market securities with maturities under 3 months such as Treasury Bills. If the maturities are over 3 months then they should be included in Short Term Investments.

 

Expanding the Definition

Cash and Cash Equivalents has a very tight definition under GAAP, however some firms attempt to artificially increase the cash balance by using a aggressive definitions for cash. Demand Media (DMD) accounting policies per the 2012 10-K define Cash and Cash Equivalents as :

.. all highly liquid investments with a maturity of 90 days or less at the time of purchase to be cash equivalents. The Company considers funds transferred from its credit card service providers but not yet deposited into its bank accounts at the balance sheet dates, as funds in transit and these amounts are recorded as unrestricted cash ….

 

Note the second sentence which includes funds in transit in the Cash balance. Funds in transit should not be included in Cash and should be left in other balances such as Accounts Receivable.

The Cash and Cash Equivalents details in the notes to the accounts should always be examined for details on the firm’s definition of Cash. Aggressive treatments include adding funds in transit, not deducting cheques written or including some accounts receivable. Inconveniently, a note on the firm’s definition of Cash is not a requirement and is not always available (Demand Media’s accounts filed in 2013 contain no Cash definition).

 

Cash Available

The Cash balance is sometimes viewed in isolation. For example, analysts will sometimes deduct cash from a company’s market capitalization prior to calculating a Price/Earnings ratio. This assumes that the Cash balance is essentially a permanent asset of the company with no encumbrances. However, in many circumstances the cash in owed to customers. Groupon for example collects payments directly from purchasers of its ‘Groupons’ , in then pays a portion of these payments to the provider of the service approximately 3 months later. Thus a large portion of Groupon’s cash balance is pledged to service providers and will only remain with Groupon for 3 months.
In Groupon’s 2012 10-K filing Cash and Cash Equivalents is $1.2bn and ‘Accrued Merchant and Supplier Payables’ is $670m. In addition Groupon includes refunds (ie amounts that must be repaid to purchasers when a merchant fails to fulfil its obligations) in Accrued Expenses. After deducting amounts payable Groupon’s cash balance is a mere $280m.

Changes of Accounting Policy

Firms are at liberty to change the accounting policy applied to their financial results. Changes to accounting policy fall into three main categories:

1. Changes of Accounting Principle
2. Changes in Accounting Estimates
3. Changes in the Reporting Entities

Changes of Accounting Principle
In preparing their financial accounts, firms may select from several alternative accounting principles. For example, in depreciating its fixed assets, a firm may elect for accelerated depreciation (which front-loads the depreciation charge) or straight line depreciation (which allocates the depreciation charge evenly across all periods). Typically there is some guidance on which principle to apply, but no hard rules and so the firm should select the principle which it deems most appropriate.

If the firm subsequently decides that the original principle is inferior to an alternative principle it may change the principle applied. Such a change should be justified and explained in the notes to the accounts, and also needs to be noted in the auditor’s report.

Although firm can elect to change an accounting principle, most changes to accounting principle are due to new regulatory requirements which mandate the change.

Changes in Accounting Estimates
Firms are required to make estimates for wide variety of items in its financial accounts. For example, depreciation requires an estimate of an asset’s useful life, bad debt provisions require estimates on delinquency rates, stock requires an estimate of the current market value for that stock.

All estimates need to been examined and validated for each reporting period to ensure they remain valid. If it is determined that an estimate is no longer accurate, it will need to be adjusted. The frequency of changes in an estimate varies by the nature of the estimate, useful asset lives typically are relatively stable whereas provisions for bad debts will change regularly with the prevailing economic conditions.

Changes in estimates can be a method for firm’s to manage (or smooth) their earnings. Provisions for bad debts is a common item for managing earnings. A firm may make an overly negative estimate on bad debts during a healthy period which would reduce the earnings and create a liability (‘Allowance for Doubtful Debts’) on the Balance Sheet. The Allowance for Doubtful Debts liability can be later reversed in a period when the firm needs to improve earnings, in such a circumstance the liability is reduced and appears on the Income Statement as ‘Allowance for Doubtful Accounts’ or similar.

Some firms require extensive estimates in arriving at their revenue number. In such a circumstance the firm’s revenue (and estimates in arriving at the revenue) should be closely scrutinised. One example of this is Zynga. Zynga apportions the revenue from the purchase of virtual goods over the expected term these goods will be used over. This estimate is contingent on a lot of data internal to Zynga such as granular data on the time players are expected to play a particular game, and only the very high level data is disclosed in Zynga’s accounts.
When Zynga reduced its estimate of then life of a virtual good’s lifespan then it essentially accelerated the recognition of its revenue and boosted its current period revenue.

Financial Impact of Changes in Principle and Changes in Estimates
A change in principle or estimate will likely impact the financial results of not only the current period but also previous periods. There are two methods for handling the impact of the change – cumulative-effect (catch-up) or restatement. The restatement method requires the firm to restate its previous periods using the new accounting principle or estimate. More commonly used is the cumulative-effect method, whereby the firm rolls the cumulative net impact of the change for all prior periods into the current period. This amount appears as a separate item on the Income Statement, typically as the final item just before Net Income.
Also of interest to an analyst is the impact of the change for the current period. This is not broken out separately in the Income Statement but needs to be disclosed in the notes to the accounts.

Change In Reporting Entity
The reporting entity can be materially changed when a merger or divestiture occurs. Google is a good example of both. When Google’s purchase of Motorola was approved it restated its current and prior period accounts to include Motorola. Google subsequently divested Motorola Home, only keeping Motorola Mobility, this divestiture necessitated a further restatement of the prior periods accounts.
Note that a change in the reporting entity requires a restatement and the cumulative-effect method available for changes in accounting principle or estimate is not available.

Protecting Against SQL Injection In .NET Applications

Despite being so well understood, SQL Injection remains one of the most common vulnerabilities in web applications.

What is SQL Injection

Any SQL which is dynamically created has the potential for having malicious SQL injected into it. For example, the below code receives a querystring and adds it to a SQL select string which will then be executed against the database.

//Querystring for example could be ?userid=1
var inputStr = Request.QueryString("userid"); 

var sqlQuery = "select createDate from users where userid = '" + inputStr  + "'";
//sqlQuery is 'select createDate from users where userid = '1' 

All the attacker has to do is append sql to the querystring for it to execute. Thus adding 1; delete from users;-- will cause the sql statement to be select createDate from users where userid = '1'; delete from users;-- and two statements will be executed by the database. The first statement returns the createDate for the ‘jude’ user, the malicious second statement deletes all records from the database. Note that no statements added to the sqlQuery will be executed since they are commented out using the — characters.

There are a multitude of variations on these basic scenarios, as well as executing operations on the database, attackers can retrieve sensitive data by displaying it on the site which does not require execute permissions on the database. Take for example a search box on a site which places the search term in the querystring which is then used to form the SQL query as below :

var searchTerm = Request.QueryString("searchterm");
var sqlQuery = "select * from articles where article.title like '%" + "%'";

The sql is then executed against the database and the search results are output to the webpage.
A malicious user can inject sql into the search term and return a listing of table names in the database using the below ‘search’ term:

' union select name from sysobjects where type = 'u' --

Once armed with the table name listing, the attacker can target a table to return the column names using the below term:

' union select * from information_schema.columns where table name = 'users' --

Then it is just a straightforward select statement to return the sensitive data:

' union select socialsecuritynumber from users --

There are a large number of sources of SQL Injection, as noted above querystrings and form values are common sources of injection, but cookies and Http Headers are also potential sources. Http header values in particular are commonly stored in the database, for example logging the referring url is common practice on many sites:

var referringUrl = ServerVariables("HTTP_REFERER")
var insertReferralSql = "insert into trafficreferrals   values ('" + referringUrl + "')"

The Http Post can easily be tampered with using a tool such as Fiddler and malicious code entered in the Referrer field in the header. Note in this particular instance, the .NET framework provides the Request.UrlReferrer property which will pass back a valid Uri and should be clear from injected code.

Problematic Fix – Manually Cleaning Strings

Before looking at robust defenses against SQL injection it is worth looking at ad-hoc protections which are often ineffective and should not be used.

Writing custom code to ‘clean’ the input string of dangerous characters is effective in theory but needs to be done with extreme rigour and many solutions can very easily be bypassed.

For example, the potentially hazardous ‘ and – – characters can be removed as below :

var inputStr = Request.QueryString("userid"); 
var cleanStr = inputStr.Replace("--", "") 
                       .Replace("'", "");

This may also be performed on SQL Server using the TSQL REPLACE function:

...
set @input = REPLACE(@input, '--', '')
select @input
set @input = REPLACE(@input, '--', '')
select @input
...

In this example the cleanStr may be consider safe of the ‘ and – – sequences. However this is not the case. Consider the below input string:

; delete from orders -'-

Note the -‘- sequence, in this case the ‘ character will be removed after the – – characters are tested for and the — character sequence will then be created leaving the below string:

; delete from orders -'-

The ‘ and – characters are not always necessary for attacks. Consider the first example we looked at

var inputStr = Request.QueryString("userid"); 
var sqlQuery = "select createDate from users where userid = " + inputStr 

In this case the below SQL could be injected without the ‘ and – characters :

19; delete from users;

If the database has SET QUOTED-IDENTIFIER OFF then attacker could simply replace the ‘ character with ” .

Defenses Against SQL Injection

Ensure Correct DataTypes Are Input
In many of the above scenarios an integer was expected and the attacker passed in an SQL string instead.
In the application we can test the input is in the correct format :

int orderId = int.Parse(Request.QueryString["OrderId"]);

//The below code can be problematic when users have different date formats
//Consider also DateTime.TryParse
DateTime orderDate = DateTime.Parse(Request.QueryString["orderDate"]);

This ensures that strings are not input when integers, date formats and other datatypes are expected. This step is sometimes seen as unnecessary overhead when parameterised queries are used but it is does provide additional protection.

Parameterised Queries
Parameterised queries are a primary defense against SQL injection. The below stored procedure uses a parameter on the where clause which will prevent malicious code being injected.

CREATE PROCEDURE GetUserJoinDate 
    @UserName nvarchar(50) 
AS 
    SELECT JoinDate
    FROM Users
    WHERE UserName = @UserName 
GO

Parameters are not always effective however, and building dynamic SQL using string concatenation can introduce vulnerabilities. The below stored procedure performs the same operation by using dynamic SQL.

CREATE PROCEDURE GetUserJoinDate(@UserName nvarchar(45))  

 AS
  DECLARE @sql nvarchar(255)
  SET @sql = 'SELECT JoinDate FROM Users WHERE UserName = ' + @UserName + '
  EXECUTE sp_executesql @sql
GO

In this case the below SQL passed in as the UserName parameter will execute malicious SQL on the database:

'; delete from users --

This is a very simplistic sample and is an unusual use of dynamic SQL, dynamic SQL is more commonly used in other scenarios where the developer may believe it is the only option. For example SQL is often passed in to build such as sorting where parameters

CREATE PROCEDURE GetUsers 
    @Sort nvarchar(50) 
AS
  DECLARE @sql nvarchar(255)
  SET @sql = 'SELECT UserName FROM Users   ' + @Sort 
  EXECUTE sp_executesql @sql
GO

This allows partial sql to be passed in for sorting:

exec @Sort = 'order by UserName ASC'

This stored procedure could be purged of dynamic SQL and written as below:

CREATE PROCEDURE GetUsers 
    @Sort int = 1 
AS
   SELECT UserName FROM Users
   ORDER BY CASE
     WHEN @Sort = 1 THEN ( Rank() OVER (ORDER BY UserName ASC) )
     WHEN @Sort = 2 THEN ( Rank() OVER (ORDER BY UserName DESC) )
     WHEN @Sort = 3 THEN ( Rank() OVER (ORDER BY CreateDate ASC) )
GO

There are numerous scenarios such as this where dynamic SQL can be removed. If dymanic SQL is absolutely necessary then string concatenation should be avoided and parameters placed within the SQL which will will ensure that the parameter is properly escaped:

CREATE PROCEDURE GetUserJoinDate 
  @UserName nvarchar(45)
AS
  DECLARE @sql nvarchar(255)
  SET @sql = N'SELECT JoinDate FROM Users WHERE UserName=@UserName'
  EXECUTE sp_executesql @sql
GO

These examples have focused on stored procedures on the database, but this applies equally to SQL created in the application :

//Vulnerable
SqlConnection conn = new SqlConnection(connectionString);
SqlCommand command = new SqlCommand("SELECT JoinDate FROM Users 
                                     WHERE UserName='" + userName + "'", conn); 

//Secure SqlConnection conn = new SqlConnection(connectionString); SqlCommand command = new SqlCommand("SELECT JoinDate FROM Users WHERE UserName=@UserName", conn); command.Parameters.Add(new SqlParameter("UserName", userName);

Permissions

The database is only vulnerable to SQL injection to the extent of the user’s permissions on the SQL Server database. It is thus essential to audit and limit the permissions on the database, a detailed discussed of permissions is beyond the scope of this article but a good starting point for auditing SQL Server permissions is Auditing SQL Server Permissions

IIS Global Filtering
As an additional defense for querystring injection, IIS can filter requests for dangerous keywords. This can be done globally using the applicationhost.config (located at %systemroot%system32inetsrvconfigapplicationhost.config ). Under the tag add your rules as below:

 <filteringRules> 
    <filteringRule name="SQLInjection" scanQueryString="true"> 
        <appliesTo> 
            <add fileExtension=".asp" /> 
            <add fileExtension=".aspx" /> 
        </appliesTo> 
        <denyStrings> 
            <add string="--" /> 
            <add string=";" /> 
            <add string="/*" /> 
            <add string="@" /> 
            <add string="char" /> 
            <add string="alter" /> 
            <add string="begin" /> 
            <add string="cast" /> 
            <add string="create" /> 
            <add string="cursor" /> 
            <add string="declare" /> 
            <add string="delete" /> 
            <add string="drop" /> 
            <add string="end" /> 
            <add string="exec" /> 
            <add string="fetch" /> 
            <add string="insert" /> 
            <add string="kill" /> 
            <add string="open" /> 
            <add string="select" /> 
            <add string="sys" /> 
            <add string="table" /> 
            <add string="update" /> 
        </denyStrings> 
    </filteringRule> 
</filteringRules>

/* Courtesy Wade Hilmo */

This will deny requests with these keywords in the querystring.

Leave ValidateRequest On
ValidateRequest is inbuilt in ASP.NET and throws an error whenever a page is submitted with potentially malicious content. However, ValidateRequest is very aggressive and out of frustration developers frequently resort to turning it off in across the entire application. Instead, it can be selectively disabled for controls, pages in ASP.NET and for controllers in ASP.NET MVC (using [ValidateInput(false)] ). This gives more granular control over where there are potential exposures to SQL injection.

Consider Using an ORM
Object Relation Mappers such as Entity Framework or Nhibernate take control of the SQL generation and execution and generally do an excellent job of protecting against SQL Injection.