What began 8 years ago, as a product that could aggregate multiple company files for basic financial statements, has now morphed into an incredibly powerful tool capable of handling options regardless of how people input their data into QuickBooks..
Many of the measures - and analytics - are fulfillments of our early thinking; some are specific customer requests, and believe it or not, some are morphed during the programming process. In other words we take advantage of the results of the creative thinking process.
We had two goals with this version - aside from the bug fixes, and customer suggestions:
Both of these goals overlapped each other, so it was a fair combination of raw implementation, creative thinking, and lots of what-if scenarios - to bring you even more options to dice and slice your data.
In QuickBooks you basically have two main reports to determine profitability
Budgets that you enter by job (and/or class) are not available in the Intuit SDK, so we use the Custom Reporting feature to grab that information.
QuickBooks uses only aggregation of estimates, costs and revenue to derive the measures in that report. QQube adds the related and linked transactions to make it easier to see everything at a glance:
This does not include the other family of measures e.g. categorize by labor, materials, other; billed/unbilled amounts; and of course theoretical billing vs actual billing using billing rates, item rates, or price levels.
One of the major reasons people purchase QQube is for the ability to get linked information. In some cases it is because QB doesn't do it underneath the hood e.g. tying a specific vendor bill to a specific customer invoice. In other cases it something simpler, such as received revenue, or the value of unbilled time.
However, the definition of what comprises a particular linked transaction in QQube, is somewhat subjective - because there are times where you can't compare back to a specific report in QuickBooks.
There is no more evident than in the new job costing measures we implemented.
In order to determine what is open/paid/applied you MUST have access to all the possible linked transactions. But of course, the SDK is missing a few.
It means the Accounts Receivable and Payable are literally impossible to reverse engineer - and why we use the actual SDK report pulls to achieve our own A/R and A/P analytics.
So, we used QB Enterprise Custom Reporting to get those missing links, so there *may* be some cases where Pro/Premier have inaccurate linked measures. But for purposes of this blog, we will assume everything is available.
Everybody looks at their data differently. We have used this mantra for several decades, and it is especially true in job costing - and sales analytics.
If somebody wants to know what discounts, or reductions have been given in the course of their sales, there are several sources and methods. Consider this:
Then we get into what is applied:
Does this make your head spin yet?
I am not going to delineate all of the fine details about how this all works. Rather my point here, is that we have given you more ways to get what your client wants if they decide to use QuickBooks "as it wasn't intended". We also gave you more ways of matching back to QuickBooks reporting.
The fields are similar for both Sales and Job Costing Analytics
Of course we always had the Unapplied Credits - which is a non-linked transaction.
This is an actual job costing file from a customer who was willing to help us get better.
First, let's look at the Income side of things:
Estimated Income and Actual Income match QB Estimated vs Actuals (A and B) exactly.
Open A/R + Unapplied Credits, match QB A/R Aging Summary report (C) exactly.
We added columns to allow people to see what types of credits were listed on the original invoice e.g. "Credits Applied ON Doc" and "Payments Applied ON Doc"
Also a Column called "Credit Memo Applied TO Doc"
"Credits Applied ON and TO" flow through the Income column, so there should be a theoretical match between Payments (and Credits) Applied To Doc and Income Paid. However, this file had some "Unapplied Income" from Journal Entries and Deposits.
We know that the applied payments (which includes any applied credits) is accurate - but only through the Intuit SDK, as there is no report in QuickBooks that can be matched to.
NOTE: Payments applied TO documents includes not only actual payments, but any applied credits.
So Bottom Line: we know we are accurate, as Income - Open A/R = Income Paid; and Income Paid was the calculated portion with the remainder shown as Open A/R.
Let's Look at the cost side of things.
QQube Estimated Cost = QB Estimated Cost in Estimates vs Actuals (AA) within .13 cents.
QQube Actual Cost = QB Actual Cost in Estimates vs Actuals (BB) exactly.
QQube Job Cost Open Amt = QB Unpaid Bills by Job Report (CC) exactly.
As to the .13 difference, it is generally the result of corruptions in an old file (10 to 20 years of data), as estimates did not have some of the data entry rules it has now.
Go here for more information on the QQube Version 7.1 release