As many readers know, Walter Hamscher is an XBRL pioneer and one of the smartest people in the field. He recently gave us a wide-ranging interview in which he discussed a host of XBRL topics, including the SEC’s proposed mandate, the pace of XBRL adoption in the US and abroad, assurance issues, and Inline XBRL. The third part of the interview, which begins with question (6), appears below. The first and second parts were published over the past two weeks; we’ll publish two more installments over the next two weeks. 

(6) There's been much discussion about the use of extensions in XBRL. From one point of view, they allow companies to adopt the language to their particular circumstances; from another, they allow companies to indulge in creative accounting and make financial statements less comparable.

The Pozen Committee's Progress Report stated that, because of the development of US GAAP taxonomies, there will be less need for customized extensions. Do you agree with that assessment? Do you think the extension issue poses the major problem for preparers and users of financial statements? Or will it now be only relevant for a limited number of companies?
 
Actually, I disagree with a premise of the question. When I hear that it's going to make financial statements less comparable -- less comparable than WHAT? Less comparable than the mess that you have today? No, you can't make it any worse. So it may be the same, it may be better but it can't be any worse.

That said, I do think that the Pozen Committee is absolutely right. We invested a huge amount of effort in the US GAAP taxonomy with a large vocabulary with that intent and architecturally designed it in such a way that the extensions would be not only less necessary but a lot more predictable, easier to do them the right way, if you will. Does the extension issue pose a problem for preparers? No. It's actually the solution, not the problem.

There’s a very interesting phenomena I've observed which is if you talk to people who are in the business of supplying data or tools to investment analysts, they say extensions are a problem.

Yet I have not heard any sophisticated, professional analyst, who is actually doing financial modeling, who is actually making business decisions, who has ever indicated that that was actually a problem. On the contrary, they see it as actually a huge step forward from the mess that we have today.

So I think you have got to be cautious when you hear people who are not professional analysts speak on behalf of analysts and give you the hearsay this will make analysis more difficult. First of all, ask if that person is really an analyst or a software vendor supplying to an analyst -- that's a very different perspective. Then ask whether widely held stocks are the ones that will have the most extensions. If you actually look at the last five years of data -- and like all computer people that's kind of the way I look at things, I always want to see the data first -- look at the distribution of unique line items (never mind tags, but just unique line items used in financial statements), it's actually the smaller companies that have much more need for extensions than the large ones.

Here's why. If I’m Van Camp and my business is frozen foods, my revenues are so aggregated that you can say, yeah, this is the food industry and these are foods -- you don't need to distinguish between the different types of fish. If I am a small salmon importer, however, I may very well need to distinguish revenues from West Coast salmon and East Coast salmon.

I think we may be seeing people commenting on XBRL and extensions without really every having done anything with it. They have never actually tried modeling companies, and they've never actually read, for example, the US Taxonomies Preparers Guide, which spells out what constitutes a good extension. How do you do it so as to minimize your own effort and maximize the usefulness of your statements? There's a lot of good information in there, and I confess that it frustrates me that we have people commenting on things who haven't taken the time to actually go and read how it's done or tried it.

I find it very interesting that Jeff Diermeier, head of the CFA Institute completely understands why it's going to make things easier than they are, whereas software vendors who are worried about “this is not normally the way that XML works” or “this is not a flat finite table of standardized line items” are just missing the point. They don't understand how much of an improvement it is over the current text-based mess.

(7) On May 14, the SEC voted to propose a rule for the adoption of XBRL for financial reporting. Was the proposal more, less, or about as aggressive as you had expected? Was there anything in the proposal that surprised you? [NOTE: The interview with Walter was conducted before publication of the proposed rule on May 30.]

I guess it was more a sense of what was left somewhat open in the proposal. I wouldn't say it was a surprise; it was more of a recognition that they are seeking to fully understand all the implications of alternative proposals. For example I think people are going to be very dissatisfied with text blocks as a method for notes, even if the phase-in schedule allows it only for the first year of a company’s filings. I don't think that's going to last very long. Preparers are, frankly, more likely to make tag selections for the face of their financials that might have to change later to line up with tag choices in the notes, and that’s not good. Most definitely, analysts certainly don't get any benefit from block text. That's a part that I hope will evolve in the next few months to a more refined, sophisticated notion of how it can be done.

My understanding was that block tagging would be for the first year, but then for the second year you would have detail tagging.

Yes, I guess what I am driving at is that feedback will drive the SEC to a clearer understanding that will evolve to the point where they will be able to be a lot more specific about what those detail tags would look like, how they should be done. What I would predict is that there will be commentators who will start to look at the new filings, look at the text blocks and say, well, this is dumb, and they will be right.

I also was more surprised it didn't say very much at all about attestation standards or assurance standards around the XBRL document. It seems perfectly clear to me what to do, and I guess there's just been a communication gap or something, and a lot of people attending to other things. But I think it's a solvable problem and I think it would tremendously increase the value of XBRL documents if they did have an assurance standard associated with them and a clearly defined mechanism for doing that. So, they are seeking input, and I believe it is another thing where the SEC needs to have a solution; because I think people will point at it and say “I can't use this XBRL data -- it does not have an opinion on it.”

(8) Could you describe that assurance mechanism, and how you think it could be accomplished?
 
The basic idea here is, if you look at some of the proposals that have been made about how to indicate assurance in an XBRL document, they have a major flaw: they presume that the person preparing the document is the one saying that he has assurance on its contents. That flies in the face of the whole notion of assurance; assurance is a comment on somebody else's document. I have a webpage hosted which shows exactly this.

Basically, you would take the opinion and have it point to all and only the facts in another report to which your assurance should apply. So when you say this report taken as a whole [presents fairly the financial position…], there is a very specific technical notion of what it means to “take it as a whole.” You point to all of the facts that are included, and you don't point at any that are not included. You can take that document containing the opinion -- it lives separately from the original, you can sign it, you can encrypt it -- and do all those fancy things that you want to. But it's under the control of the auditor rather than under the control of the publisher of the document.

So what I did was create a little example in which I simply took a hypothetical attestation that someone might give on one of the Microsoft filings. I posted it on my website and it has pointers to all of the facts in a Microsoft filing on the EDGAR site.

So that way a user can look at the document and follow every one of those links and basically construct just a document with just the numbers and the facts and the assertions that the management has actually made to which I am actually attesting.

So it's a very important notion here. You don’t want preparers to be applying a tag that says that this was or was not audited…it’s not their job to do that.

As many readers know, Walter Hamscher is an XBRL pioneer and one of the smartest people in the field. He recently gave us a wide-ranging interview in which he discussed a host of XBRL topics, including the SEC’s proposed mandate, the pace of XBRL adoption in the US and abroad, assurance issues, and Inline XBRL. The second part of the interview, which begins with question (4), appears below. The first part was posted last week; we’ll publish three more installments over the next three weeks.

(4) Arnold Hanish, Chairman of the FEI's Committee on Corporate Reporting, recently said that he expects most companies will stick with the bolt-on (as opposed to integrated) method of furnishing XBRL exhibits, thus "yielding no benefits to preparers." Do you agree with that assessment? Do you think that companies' use of XBRL will naturally evolve from bolt-on to an integrated approach where they can realize the full benefits of XBRL adoption -- or are you concerned that many firms will seek merely to comply with the SEC mandate and continue with the bolt-on approach?

There is a whole spectrum of interpretation as to what that statement means. At one very simple level, he is saying: nothing ventured, nothing gained. He also in some sense is jumping past the software to the XBRL, recognizing that in the short-term right now, corporate software tends not to have XBRL fully integrated into it -- and it's not even particularly easy to locate the plug-in module for whatever enterprise software or reporting product you happen to have at the moment.
 
But there are indeed separate products, products that are really XBRL native; but these other products are not necessarily aimed at Fortune 500 sized companies, and they don't have nearly the mindshare that some other products that we’re familiar with. It’s also a difference of perspective. For Fortune 500 companies, it is so easy to do the bolt-on approach, in the same way that it's easy for them to hold an office Christmas party. It is just an expense, and they put down their money and they move on; it doesn't really impact their operations.

On the other hand, if you look at an Eli Lilly [NOTE: Arnold Hamish is Lilly’s Chief Accounting Officer], you notice that in the past couple of months, they actually are going through a rather large internal transformation centering around streamlining and making more efficient what they regard to be the core of their business, which of course is patient care and patient health. Naturally that is where Eli Lilly is focused as a consequence of its size. Access to capital markets is not an issue for them.

But now stop and think about smaller companies. It may be that in big companies, the preparers feel very much divorced from the fate of the company itself; the smaller the company, the more it is obvious that the preparer benefits from financial transparency -- for the simple reason that financial transparency is what lowers their cost of capital. Eli Lilly's cost of capital is probably not nearly what it is for a smaller company.

So the consequence of that is, of course, the larger the company, the more they regard the process as “this is just a burden, we already have all the access to capital markets that we need.” The smaller the company, the more XBRL is going to look like a bargain as the software comes online to actually make this work.

Consequently, the way I look at Arnold’s statement is that it’s true for large companies at this particular point in time. But I also think it's focusing on the high end of the spectrum where I agree that a big company could get a short term benefit from XBRL, whereas as a midsize or a smaller enterprise is probably in a much better position to do that.

(5) Well, to make sure I am understanding you correctly, are you are saying that a smaller company would be more likely to move more quickly to an integrated approach for XBRL as opposed to the bolt-on approach?

I believe that if they were looking at it just from a cost of ownership and business value of the implementation that's true. Of course, small companies have lots of other things on their mind. But if you start with the premise that for smaller companies access to capital markets and transparency have greater marginal value to them than it does to large well-known companies, apart from that you say, “we want to get these XBRL reports out, we want to get them out efficiently… but the bolt-on approach doesn't look very efficient, does it?” No, and it's not.

Let me just expand on this a little further. I know this mid-size company in Connecticut which has about 40 subsidiaries.  For a small- to mid-sized company, that data integration problem is fairly significant and it's a cost to them; yet they are small, and so access to capital is always a problem. So for them, it seems to me that the trade-off to using XBRL to get control of their internal data is a much better value proposition, given that it also enables as a side-effect they are reporting in XBRL to the capital market. (By the way, Ralf Frank from the German Society of Investment Professionals had a very good presentation at the recent international conference at Eindhoven that spoke to these issues.)

I think that, once again, if you look culturally in the US, people are focusing on, “The damn government is forcing us to do this thing we don't want to do.” Instead of saying, “well, if you move beyond the regulatory mandates there is actually a streamlining opportunity here.”

Now, the fear factor is exactly what I said before, which is if you don't have a working application sitting there in front of you that you can understand in 15 seconds or 15 minutes, it is going to be a stretch for somebody to see benefits. But I think that once again some of the companies that are in this market do understand what that opportunity is. I think that once XBRL becomes an accepted part of the landscape -- rather than a new regulatory mandate -- it will be a lot more obvious and a lot easier to sell.

My point here is I think that when people look at the big Fortune 500 companies and say well, if they don't benefit from a bolt-on, yeah that's right, nothing ventured, nothing gained. Now, what about the other 9,500 US listed companies, how about them?

As many readers know, Walter Hamscher is an XBRL pioneer and one of the smartest people in the field. He is a co-author of the XBRL specification and several other XBRL International publications, a member of the XBRL International Board of Directors, Past Chair of XBRL International, and consultant to XBRL US contributing to the XBRL US GAAP Taxonomies.  Walter is President and CEO of Standard Advantage, a consultancy that helps organizations to achieve the cost savings and increased flexibility available to them through strategic commitments to technology standards.  He holds a PhD in Computer Science and Electrical Engineering from MIT. 

In this wide-ranging interview, Walter offers both specific detail and broad perspective on key XBRL topics, including the SEC’s proposed mandate, the pace of XBRL adoption in the US and abroad, assurance issues, and Inline XBRL. Below is the first part of the interview; we’ll publish four more installments over the next four weeks.

(1) You once said that XBRL will allow financial data and those using it to assume "a content management view of the world." Could you expand on what that means and how XBRL accomplishes that?

What it means is that, when you look at documents and documents being passed around and posted on sites and so on, you’re really viewing them in terms of their component parts and their linkages to each other. Notably, one particular part of what's considered “a document” may actually change its content continuously.  Different parts of the document may have different timeliness.

The canonical example is a website. You go to CNN.com or something like that and you see that in some sense the page never changes. But in another sense, the pieces, the headlines, the images and so on are constantly being updated within that framework. What makes that happen behind the scenes is a lot of either simple or complex workflow in which the pieces of the documents are essentially passed from hand to hand, from person to person, going through review cycles, and being checked for consistency with others, and tested, and so on.

When you look at accounting, it is striking that most accountants don't really think about data as data in a database. It is actually much more about the report and the treatment of the accounting.  Using the right accounting treatment is almost like a lawyer putting forward the argument for why a certain event should be looked at in a certain way.

So consequently, the way I look at XBRL documents is that they are much more oriented toward the integration of free-flowing text with numerical data that could stand on its own (“stand on its own” in the sense that you don't have to have the original layout of the table in order to understand the data in it). That allows you to take a more content management view in which a single document, say, can really be a combination of three or four other documents all put together.
 
In other words, it is another perspective on reporting that says, yeah, the “reports” really are reports. They have some narrative, they have some explanation, they have some structure, and the data gets filled into the framework of that report. It is not just a data dump.

(2) It's been about two years since you gave your fascinating XBRL GL webcast titled XBRL and SOA, in which you discussed how "XBRL taxonomies embedded within a Service-Oriented Architecture (SOA) are effective across a wide range of compliance processes both within the enterprise and within the related supply chain." Have you seen any evidence that companies are beginning to recognize the usefulness of XBRL for meeting the enormous compliance challenges they now face?

I have, although not so much in the U.S. oddly enough. Let me explain why I think that's true; this is obviously a personal viewpoint.

One of the things I have learned recently is that it seems to be very difficult for users –- i.e., almost anyone who is not a software engineer or computer scientist by trade, even some CIOs -- to think about anything other than either an application or a database. But what’s key is actually the notion of data structure, of reference data that structures other data, and the formats it appears in as it moves from file into application, across a network, back into a file, and so on. How data is structured, as distinct from a particular structure such as a set of relational tables, is somewhat of an abstract concept, really, if you’re not a software engineer.

Yet XBRL is that third category. It's not an application, it’s not a database; it’s conventions and a vocabulary for organizing data for a variety of applications. I think it's hard for people to visualize, unless they are actually seeing something happen on the screen in an application. It’s also hard to visualize or appreciate what the possibilities are.

So what I see some companies doing in other markets like France and Italy, where the regulators have adopted XBRL for bank reporting, is that the software vendors there have begun to integrate XBRL as an input format into their consolidation packages. I would not say that any of them put XBRL front and center, but it's no longer just an output format.

I think it's just a question of timing; they are two or three years ahead of us here in the United States. I am not that familiar with the situation in Japan, but I do know there are companies there, the vendors themselves, who have started to use XBRL internally. Although, of course there are many other factors involved in any specific XBRL implementation that complicate that story a lot.

(3) Let me continue with that international perspective. Some observers have said that the pace of XBRL adoption in the US lags that of overseas, while other say comparing implementation and regulatory climates as different as those in the US and China is comparing apples with oranges. What is your opinion? How do you see the pace of adoption in the US vis-à-vis that overseas? Is there anything the US can learn from adoption in another countries?

Looking back on the beginning of XBRL in 1999 or so, I can look at my younger self and realize that I had a very US-centric view of all this. One of the things I didn't appreciate was that some other countries have a much stronger culture of values like thrift and efficiency than the U.S. does. Consequently, it is a lot easier for some countries -- the Netherlands has a thrifty culture, as does Japan -- to look at something like XBRL and figure out pretty quickly that, yeah, this is good for everyone; it will be more efficient and therefore we will all benefit, so let's do it.

Now, I am not saying it is trouble-free and that everybody in these countries has jumped on the bandwagon right away. But by contrast in the United States, so many other things pile on to our considerations around business and government decisions, things that really have nothing to do with thrift or efficiency. They have to do with history, and they have to do with fear of litigation that doesn't exist so much in other countries.

In all my conversations in China, Hong Kong, and Taiwan, it was very clear that they had no concern at all about legal issues or anything like that.  It was just a matter of:  “Is this a better way of doing it? Can we take advantage of the fact that the standard has been developed?… Yes, let's do it.” The words “safe harbor provision” never came up in the conversation. It was just something that they understood instinctively was a more efficient way.

There is such a strong cultural difference that I can easily see why someone would say apples and oranges. But it is really not apples and oranges; it is really the difference between engineers and lawyers, and that's an attitude difference.

Written by Toshinori Kobayashi     Posted on June 6, 2008

Toshinori Kobayashi is director for enforcement of corporate disclosure at JFSA, the Financial Services Agency of Japan. He was responsible for the XBRL renovation project of EDINET, the JFSA’s electronic disclosure system.
 
In my previous post, I offered a brief overview of the process of introducing XBRL to Japan's EDINET system. With many countries and related agencies now looking to add XBRL to their own reporting regimes, there's been heightened interest in our second pilot program that was successfully conducted in the summer of 2007. Even though it's been about a year since the program was instituted, we are still receiving many inquiries. I’d therefore like to address some of the key points about the program.

While the first pilot in January/February 2007 was an offline program for some 50 companies (chosen by Japan's Financial Services Agency, or FSA) to check the taxonomy, the second pilot effort was a large-scale online program in which 1,233 companies voluntarily took part. For us on the EDINET team, the second program thus became a major event that propelled the XBRL effort forward. Its implications were threefold:

(1) Many companies showed a high level of interest in the adoption of XBRL to the EDINET system, with one-quarter of all listed companies voluntarily participating.

(2) The results gave us much confidence about the successful completion of the project. No major problems were detected in the EDINET system and the taxonomy themselves. Moreover, the taxonomy was found to cover over 95% of the tags needed for filings of the participating companies.

(3) Issues to be faced in the remaining half-year of the project became clear. Along with the positive results noted above, we did find some problems that needed to be addressed.

Let me focus on Point (3). As mentioned above, 1,233 companies participated.  Among them, 962 companies (about 80%) were able to complete electronic transmission of their financial reports in the XBRL format. Up to now, when Japanese companies needed their financial reports prepared, over 90% contracted with specialty printers for support. In the second pilot program, 78% of participants received support from financial printers. While 97% who used financial printers were successful in electronically filing their statements, 82% of companies who didn't receive help were unsuccessful.

Thus, we learned that one essential for ensuring the smooth introduction of XBRL-mandated statements in the current fiscal year was to have printing firms with the skills to handle XBRL filings available on a wide-scale basis for companies to use.
 
Regarding the companies that were unsuccessful, we have to recognize that this was their first attempt at such filings. Nevertheless, it became clear that filing XBRL reports is a significant challenge for companies without sufficient skills, which made us recognize that it would be necessary to adopt several measures quickly (as I will discuss later). 

A survey conducted by the FSA of the firms that failed revealed two major reasons for their lack of success, each of which was reported by more than 30% of the companies.  One was difficulty in using the software tools and insufficient information about obtaining those tools (the specific answers were "We didn't understand the methods for producing XBRL data" or "We didn't have tools or services for creating XBRL data"). The other was time constraints (i.e., "Because our people were busy with other work, we weren't able to devote sufficient personnel and hours to preparing the statements" or "It was taking more hours than we had allotted for the task").

As expected, when all companies in the pilot program were asked about the issues they faced in preparing statements, they mentioned the problems of tools  (i.e., "the cost of tools and services", or "difficulty in using tools"). Others cited "difficulty in determining the account title (since many choices were possible),” or "the large amount of preparation materials and the big manual" and "the manual was hard to understand." Interestingly, some companies mentioned the difficulty in coming to an agreement with the auditor on the selection of account titles.

Companies which successfully completed the filing were also asked about the estimated amount of work involved (i.e., number of hours X number of people) in creating the statements. For the first year of preparing the statements, 22% of respondents said the amount of work would be twice that for the HTML statements used up to now, and 50% said it would be 1.5 times to 2 times. Thus nearly three-quarters of successful firms said they estimated that in the first year the amount of work involved would be 1.5 times or more than previously.  On the other hand, some 14% said the amount of work would be unchanged; no companies said there would be a decrease.

Looking toward the second and subsequent years, however, only 6% of companies estimated there would be twice as much work as there was in preparing HTML statements, and the proportion who said 1.5 times to twice as much effort fell to 28%. Those anticipating the amount would remain the same was 50%, while 4% said it would fall.

Finally, it is worth noting that, if we analyze the data submitted, 30% made some sort of error in FRTA rules, and 30% made an error in FRIS rules.

The problems from the pilot program listed above had been generally anticipated. However, rather than EDINET system and technology issues, the question that was most urgent was how we at the FSA could support the reporting companies so that the transition to XBRL would go quickly and smoothly.   Given this imperative, in the second half of the fiscal year, we took the following steps -- concomitant with the development of the system and taxonomy -- to ensure smooth operation of the new EDINET system:

(1)  Improvement and Completion of Guidelines
We had been providing three types of guidelines for users: (1) creation of a taxonomy tailored for each company; (2) creation of instance documents; (3) selection of the right account item. We made these guidelines easier to understand based on the feedback from users in the pilot program.

(2)  Extensive Meetings on XBRL
We had already conducted meetings on XBRL with companies in the past, but we arranged 30 more in January-February 2008 to help reporting entities gain a deeper understanding of interactive data. In total, 4,000 companies participated.

(3) Outreach to Software Vendors
We exchanged information closely with software vendors and pushed them to develop tools that were easier to use. Specifically, we provided ideas about tools handling FRTA/FRIS violations in a better way (in order to reduce the number of violations).

There are various challenges to overcome to introduce XBRL successfully to a system such as EDINET. While we tend to devote much of our energy to technical issues, such as taxonomy creation, a smooth XBRL introduction is realistic only when the business world is completely prepared. We also need to devote our efforts to the needs of actual users. It was this point that gave the pilot program particular significance.

Let me now focus on the very high level of participation in the second pilot program, which I noted exceeded 1,200 companies. The high number has surprised observers outside Japan, and to be honest, it surprised me, too.  Initially, we thought at best 400 to 500 companies would participate. Even that level seemed very high, given the few dozen in the SEC's voluntary program (VFP). Participation in the Japanese program was completely voluntary. There were no restrictions, either direct or indirect, placed on those who didn't want to participate. At the same time, there were no limitations placed on those who wanted to participate. 

Why, then, did over 1,200 companies voluntarily choose to join?  The answer to this question – on which we have received many inquiries from overseas agencies -- appears to be embodied in the following four points:

(1) The Prospect of an XBRL Mandate in April 2008
Companies pondering whether or not to join the pilot program knew well that XBRL would be adopted for financial reporting in April 2008.  For many firms, this expectation gave them the sense that participation in the pilot program was a necessity.  The appeal of the pilot program to reporting entities was that it would be an online test of the system and taxonomy, which would give them practice and experience in XBRL filings.

(2) Aggressive Outreach by the FSA and Others
The FSA aggressively sought to recruit companies to the program, conducting ten meetings for the purpose. In addition, we also relied on the Keidanren, the Tokyo Stock Exchange, the Japanese Institute of Certified Public Accountants, the Investment Trusts Association, and other associations to spread the word. The printing firms noted earlier also were important in informing their client companies about the program.

(3) Enlisting Software Frims and Printing Companies for Support
Detailed information on the pilot program was provided to software vendors and printing companies early on. The former were able to provide cost-free tools for pilot program use and the latter were able to offer support services, thereby reducing the burden to participating companies.

(4) Filed XBRL Data Was Not Made Public
Most of the filed data was not made public (with the exception of that for ten companies that agreed to release it for reference purposes). In addition, since it was a pilot program, we were lenient in accepting data that was not of the highest quality. Thus, companies didn’t need to be concerned that their reputations might suffer from the publication of XBRL data of insufficient quality, which stemmed from a lack of experience with interactive data.

Needless to say, the environment and terms under which any country or agency introduces and mandates XBRL can vary greatly from those in Japan. Nevertheless, I hope that some of the details and implied suggestions I've related about the Japanese experience will be useful to those who are seeking to introduce XBRL in their specific jurisdiction. 

Buying phentermine online
Insulin
Viagra jokes
Nizatidine
Oxytetracycline
Buy phentermine no prescription
Hydrocodone com
Glatiramer
Herbal phentermine forum
Meridia
Abilify
Eon phentermine
Diet diet dieting phentermine pill
Xanax and grapefruit
Macrodantin
Order phentermine online and cod shipping
Pyridostigmine
Xanax online no prescription
Low dose of viagra
Online viagra sales
Generic viagra online
Natural alternative to viagra
Phentermine picture
Cialis drug for impotence
Can woman take cialis
Lotrimin
Buy phentermine online without prescription
Phentermine without prescription and energy pill
Phenytoin
Glucophage
Digitalis
Online pharmacies phentermine xenical meridia
Leuprolide
Viagra tablet
Generic fioricet
Hydrocodone m357
Erectile dysfunction viagra
Cheapest phentermine free shipping
Cialis comparison levitra viagra
Methylergonovine
Viagra sale
Bob dole viagra
Buy cheap domain onlineoutdoorscom xanax
Lexapro and phentermine
Desipramine
Darvocet
Amantadine
Diet free phentermine pill shipping
Difference between cialis and viagra
Buying viagra on line
Viagra overnight shipping
Singulair
Cash on delivery for phentermine
Micronase
Lowest prices on phentermine
Adipex phentermine prescription
Viagra supplier
Buy get online prescription viagra
Minocycline
Different types of phentermine
Price for generic viagra
Phentermine about withdrawl
Amiloride
Addiction tramadol
Cetirizine
Tramadol side effects
Phentermine shortage
Drug information on xanax
Diovan
Buy free phentermine shipping
Diet phentermine pill
Epirubicin
Viagra doses
Phenergan
Phentermine and glaucoma
Cialis information
Generic viagra online pharmacy
Best price phentermine
Xanax long term use
Phentermine insulin
India generic viagra
Methdilazine
Phentermine 37.5 cheap
Phentermine and birth defects
Where can i buy phentermine
Oxycontin xanax bars perclesept and lortab wha
Withdrawal from xanax
Levivia viagra online
Cheap viagra pills
Cialis free sample
Order xanax overnight
Tramadol drug interactions
Phentermine referring report urls
Adipex meridia phentermine xenical
Cheap phentermine
Soma muscle
Phentermine 6 pm order
Humulin
Lexapro
Protriptyline
Phentermine lose weight loss diet pills
Loracarbef
Octreotide
Sparfloxacin
Meridia sibutramine
Prozac drug interaction with xanax
Caffeine
Klonopin xanax
Buy online pharmacy viagra
Efavirenz
Sertraline
Viagra pharmacy
Buy Celexa
Labetalol
Buy cialis generic online
Pediacare
Generic tramadol
Herbal viagra reviews
Discount viagra sales
Tetracycline
Canada xanax
Aprobarbital
Diet information phentermine pill
Price viagra viacreme
Bush inauguration speech draft viagra bastard of
Cheap phentermine no shipping
Fluticasone
Phentermine prescribed online
Viagra commercial
Phentermine in stock
Phentermine medical insert
Delavirdine
Viagra 6 free samples
Vicodin online
Generic viagra india
Cheap phentermine cod
Diazepam
Mecamylamine
Buy vicodin
Androgel
Cheapest place to buy phentermine online
Meridia
Combivent
Buy and purchase viagra online
Phentermine ingredients
Avandia
Lowest prices viagra
Lorazepam
Phentermine affordable
Adipex between difference phentermine