For a much more thorough description of the intricacies, check out this post on CNet about the issue.

As some have pointed out in private correspondence, there is, in fact, no requirement that this be done exactly the way Apple is doing it. However, it is a requirement that the revenue recognition be defensible. As such, the other choices they could have made were not very appealing, such as deferring revenue.

The long term consequences of these regulations, from an accounting and business perspective are unclear, and probably nowhere more so than in the software business. If, for example, your software sales price includes free upgrades to the next version (or even the next minor upgrade and that minor upgrade includes features), you might be required to spread the revenue from that customer out over the time between the time that you sell them the first version and the time that you sell them the last version.

The assumption here is that you are "liable" for providing the customer something over the long haul and thus you have not yet earned the money that you've collected. Thus, in the world of accounting, you must show on your books that you have unearned income, that will be earned at a later date when you make good on your promise to the user.

This is certainly an interpretation. I'm not sure that I agree with that take on things, especially if the value of the future upgrades is not perfectly clear, or bounded by time. If I choose (as a software producer) to give my customers something to keep them happy, I'm not sure why that can't be accounted for as a marketing expense aimed at maintaining customer loyalty and thus an SG&A expense in the P&L. Instead, the regulations want me to call it a cost of goods or development expense and write it against previously unearned revenue that is now earned.

In the past, the software industry generally considered that sales were composed of two separate products: the product, and the support. In some cases, software support (upgrades) were promised for a particular time period (12 months or 3 months are common). In this case, that's included support and works just like paid support would. For this type of arrangement, it is hard to argue that the revenue has been earned already.

However, many companies sold version 1.0 of a product and promised "free upgrades" until version 2.0 came out. This is still a pretty common occurrence for some companies, but could cause them some real problems as they get bigger. Since versions of software often linger, it's not out of the ordinary for new features to sneak in (or even be touted) during the 1.1, 1.2, 1.3, etc. timeframe. If this is the case, an argument can be made by an auditor that the company didn't appropriately account for the product revenue because the 1.1, 1.2, 1.3, etc. versions should deserve some revenue share and thus any version to come from that time on should as well.

In the end, I think this is going to have a chilling effect on software updates and might well lead to some annoying future problems. One question this leaves me with is whether Apple has chosen not to support my phone on iSync because the "feature" didn't exist in 10.4 and they didn't want to start pushing back Tiger revenue because of this. What else might fall down this way?

If you look carefully through Apple's 10.4.x updates over the last 18 months, they seem to list everything as "fixes". Prior to 10.4.3, some of the updates were stated as including "improvements", but it appears that verbiage has gone away.

Anyone else want to comment on this?