Intuit QuickBooks Deathwatch 2 / Xero Add-on Updates, Intuit QuickBooks Deathwatch 3

Mike Block at QuickBooks-blog.com writes his Deathwatch 2 installment: Early Intuit surveys showed that those with an add-on were much more loyal and updated QuickBooks many times as often. However, I have been tracking web pages with QuickBooks add-ons links for years. They use pages with QuickBooks and words like interface or link to. My Google search showed these numbers on:
          09/06/10                        Two million
          06/10/11                        Nine million
          12/18/01                        Twenty million
          06/22/13                        Eight million
          09/10/13                        Six (6.07) million
                                                (down 70% in 21 months)
This same search, for Xero add-on links, showed these numbers on:
          September 10, 2013      Two (1.84) million

QuickBooks desktop recently lost 800,000 users (20%), while QuickBooks Online got 600,000 users, for a 200,000 net loss. Xero got 200,000 users starting later. Xero has long grown far faster than growth in QuickBooks Online. Based on current growth, Xero users will exceed QuickBooks Online users in two years. Xero is actually doing much better than this because only QuickBooks Online counts trial users or the separate users of multi-user accounts.

Mike Block at Quickbooks-blog.com writes: Xero Add-on Updates / Deathwatch 3
As announced at the recent Xerocon Dev Day in Sydney and at Xerocon US, Xero’s latest API (Application Programming Interface) updates are stacked with improvements to make Xero add-on integrations a little bit easier. The differences between the Xero and Intuit (QuickBooks) approach are a big reason for my Intuit QuickBooks Deathwatch series.

 The Xero API now supports credit note refunds. This offers more advanced job management, ecommerce and retail integrations with Xero. It adds many additional elements on GET requests, so you can access things like discount rates, batch payment details and tax rate component details.

Default payment terms are now accessible, both at an organisation-wide level and for individual contacts. These defaults are only in the Xero app, but you can to make them options in your developer app.

Xero made the Profit & Loss and Balance Sheet reports more flexible, so you can retrieve them using the standard layout, not a user specified version. This is particularly useful for their growing range of reporting tool partners. Xero also updated the Payroll API with a Settings endpoint, to allow easier setup options when initially connecting to Xero.

Xero developers also can now retrieve expected and planned payment dates for individual invoices, so cashflow management apps can put this data to great use. Bill.com showed us how incredibly fast and easily this managed cash flow at Xerocon US. It used projected collection and payments dates to display cashflow, with a warning line. The then quickly revised a payment date and instantly displayed far better cashflow. 

You can get a summary of the Sydney Dev Day event from the Xero event blog post and API Roadmap. Xero is dedicating a lot of time to make things even easier for developers using the Xero API, so please keep voting to let us know what further improvements you need. 

Much of the material for this post first appeared in API updates for easier integrations in the Xero Blog. Mike Block CPA added this comment on 12 September 2013 #

This is terrific. It is terrific not only for what it does, but of because of the way that Xero keeps confirming that it will be giving users and developers increasingly expanded industry-standard RESTful API access to all our data. Equally important, nothing here or in the future roadmap will make any Xero developer program stop working or cost more.

The contrary Intuit proprietary approach kept showing developers and users that Intuit would always neglect areas of QuickBooks or keep them off limits. This would give Intuit a monopoly stranglehold on payroll or anything else that it wished. Intuit also kept making big API changes, added very expensive fees and dropped key servers. This made developers pay far more, and repeatedly rewrite programs, to keep them working.

That is why the dean of QuickBooks developers recently wrote Demise of the Third Party QuickBooks Developers. It also is why QuickBooks recently lost 70% of the web pages referring to its add-ons. 

Even if Intuit reverses course immediately, it will never overcome the bitterness and damage that its QuickBooks policies did to users and users. These are only a few of the many reasons that I am writing my Intuit QuickBooks Deathwatch series.

There will be much more on it tomorrow.