I disagree that you can't reach 100% accuracy of the known data.  If the bottom line of the data warehouse doesn't match the inputing systems, then the data warehouse creator needs to be able to explain why.  Every possible permutation can't be checked, but a good sampling can be, and should be. 

We had a consultant who built us a warehouse and said that the data shouldn't be expected to match completely.  After some investigation, however, it was discovered that he had violated the "level of granularity" rule which is crucial.  In this case the data didn't match because of a flaw in the data warehouse.

Data warehouse designers should consider stored procedure groups to self-document the steps.  They can only be created and edited in the analyzer (at least in 2K and earlier) but hopefully if someone is building a dw using the analyzer is not a big issue.

This article hit the nail on its head.  Data quality was the number one problem when we were building our data warehouse.  I agree that your data warehouse can reach 100% accuracy of the known data (assume you meant user entries).  But if the known data is not accurate, your reports are still off.

I did wrote an article about data quality before I wrote the article Problems with data warehouse.  But you are right, data quality is number one problem in building data warehouse.  Nice Article.

http://www.sqlservercentral.com/columnists/jchan/2593.asp

Janet