Everyone knows that I'm a 'geek' when it comes to QuickBooks. I love to explore how the 'front end' works and 'the back end' works, and everything in the middle. Some of the most exciting times I had while at QuickBooks Connect were product briefings and developer sessions. I have already written one or two articles covering some of the news, but now I want to give you some of the exciting, but 'geeky', stuff.
Before I get to what's new, let's spend a few moments reviewing what has been, and currently is, in terms of how QBO and Apps work together. QuickBooks Online is both an application and a flat file database that stores the data within Intuit’s own proprietary file format in the cloud. Applications that wish to connect to QBO must communicate directly with Intuit’s cloud based servers for purposes of file access authentication and data query.
QBO and Apps
To allow 3rd-party Developers to access QBO Intuit developed a series of APIs (Application Programming Interfaces). These ‘external’ APIs, when combined with several programming languages suited to cloud based applications comprise the programming structure of the Apps that many of us work with daily as supplements to our QBO Company files.
Unfortunately, the external APIs for QuickBooks Online did not make all areas of the accounting data available because Intuit has restricted certain data, or failed to develop and authorize accessibility via their external APIs to some data.
Intuit has traditionally used another set of proprietary APIs for internal purposes only. Of course, Intuit’s own internal APIs really had no restrictions, they supported the entire scope of QBO because without them those features, and data sets would not even be available within the QBO GUI (graphic user interface).
The purpose of both the internal and external APIs are to interact with QuickBooks Online. Using the APIs, data queries have taken the form of navigational XML commands issued to QuickBooks Online, which then returned record sets that qualified for the query results.
But the recent QuickBooks Connect conference revealed that there are big changes underway, and on their way, when it comes to the APIs that allow developers to build Apps that connect to QuickBooks (QBO). For several years Intuit has repeatedly told everyone that QBO was an ‘open platform’, but as I mentioned earlier there were limitations as to accessibility of some QBO data, like payroll. Third-party developers building payroll applications could only read data accessible via the APIs, and could only write payroll data to QBO in the form of traditional transactions.
But Intuit recognizes that the up-n-coming users of QBO ‘want choices’, and they want those choices in the Apps or add-ons for their cloud-based accounting software. When it comes down to it, many users may ultimately be looking to answer the question, “what cloud accounting works with my App” of choice, rather than “what App works with my accounting software?”
This reality, combined with the fact that the QuickBooks 'platform' was built on the concept that Apps would provide most of the industry specific business requirements while QBO served as the general ledger for small businesses, means that QBO must truly be not only an ‘open’ platform but a ‘transparent’ platform.
As an example, of the ‘heavy-lifting’ intent best served by 3rd-party Apps, let's use the example of a residential construction company. While QuickBooks has basic Estimate functionality that uses items and services, it's not realistic that a contractor would ever perform the type of itemized estimate in QBO that they compute using multiple spreadsheets or a sophisticated estimating software.
Even a 2500 sq. ft. home could take 100's of spreadsheet rows to accurately cost-out every detail. There could be 1000's of different items from which a builder might choose while creating their estimate. And there could be 100's of items associated with one or more change-orders if a home started out as 'spec' and then went under contract as customize to finish.
Heavy lifting App
This is where an industry-specific App like UDA Construction or Knowify, comes in handy. They do the 'heavy-lifting' in a spreadsheet-type estimating feature and then sync the data 'in summary' into a QBO Estimate.
You are saying, “Murph, that’s a very extreme example, and it makes sense, but it’s not the typical QBO users.” Well then, let's take another example.
Recently QuickBooks rolled out some major changes and functional capabilities as they relate to Sales Tax. With case law rapidly expanding 'Nexus' many retailers are finding themselves vulnerable for charging and remitting sales tax for each governmental jurisdiction everywhere that product is delivered.
QuickBooks could handle this, but could QuickBooks users? Who is going to ensure that the sales tax requirements are kept up within QBO? The reality is that an App that integrates with QuickBooks, like Avalara is a much more efficient way of complying. Again, the App is doing the heavy-lifting.
My point is that even though QuickBooks may offer basic functionality like Estimates or expanded functionality like the recent Sales Tax enhancements, that doesn't mean that Apps shouldn't continue to be developed and marketed for QBO.
In fact, App developers should be looking to develop even more Apps with bigger and better functionality. One of the primary reasons is the 'new' V4 APIs for QuickBooks.
So, you might be wondering what makes V4 so different from past APIs Intuit offered?
As I said earlier, the APIs Intuit made available for QBO were just that 'an outside developer tool', they were not the same as the internal APIs Intuit used for their product. But with V4, all of that changes, developers will be using the exact same APIs that Intuit uses. Intuit refers to it as "eating the same dog food."
Because there is only one set of APIs, everyone is playing with the same set of toys, and everyone has full access to the sandbox, and the same playground. OK that’s a childhood comparison, so toys = APIs, sandbox = application sandbox, and playground = QBO.
Thru the looking glass
This means that whatever exists in QBO, whatever Intuit has access to, the developers will have access to using the same APIs, the new V4. For developers it will be working as 'through the looking glass'.
In addition, the new V4 APIs will not only apply to QuickBooks, but other Intuit products like Payroll and Tax. In fact, V4 will become the standard throughout all of Intuit.
V4 will provide a coherent API realized by isolated and well-encapsulated services to enable developers to build applications quicker and more cost-effectively than ever before. Intuit estimates that a developer with basic skills in V4 should be able to build an initial App connection to QuickBooks within 5 minutes, or less.
Whereas all prior versions of the QuickBooks APIs have relied on XML the change to the V4 APIs will employ JSON (JavaScript Object Notation) as Intuit’s data-interchange format. It is an open and text-based exchange format that provides a standardized data exchange format well suited for web applications.
While XML works well for many application scenarios, it has some drawbacks that make it less than ideal for others. Since JSON has its roots in programming language types and structures it provides a more natural and readily available mapping to exchange structured data making it better suited than XML for the coming changes to QuickBooks.
All in all, the changes that are on their way will make QuickBooks even more viable as a platform upon which essentially any third-party App can provide the heavy-lifting that users demand. Teamed together such Apps and QuickBooks will meet the challenge of providing users with a solution to every situation.