QQube 7.1 - New Job Costing Features | CLEARIFY

Product Maturity and More

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:

1. Fix the applied/open/paid measures for both line and document levels.
2. Fix the Job Costing (and to a degree Sales) Analytic for received and open revenue, and for Open A/P Job Costs.

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.

Job Costing in QuickBooks

In QuickBooks you basically have two main reports to determine profitability

1. Profit and Loss by Job - which allows the entry of budgets by account (and/or by class) and depends upon only profit and loss accounts.  It is primarily used for small and short term jobs
2. Estimates vs Actual - which uses the estimate for budgeting, and relies heavily on items to aggregate totals for costing and revenue.  It specifically allows the accrual of costs into balance sheet accounts, and application of retention to properly adjust balance sheets for taxes using over/under reporting, and is more of a staple for traditional construction firms and organizations.

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: 

1. Open PO (remaining committed costs)
2. Payroll hours
3. Revenue received
4. Open Job A/R
5. Open A/P Job Costs

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.

Linked Transactions - the Black Holes of Reporting

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.

The SDK Disappoints - Again

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 Uses QuickBooks Differently and...

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.

Discounts and Reductions

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:

• Reduction of an item on an invoice
• Reduction of an item via a credit memo
• Discount applied as a line item on an invoice
• Discount applied as a line item after a subtotal of certain items on an invoice.
• Discount taken on the payment of an invoice

Applied Transactions

Then we get into what is applied:

• Payment line on an invoice
• Payment applied to an invoice
• Credit from over payments, etc.
• Transaction line items posted to A/R or A/P that can be applied directly or with a payment

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.

What we Added

The fields are similar for both Sales and Job Costing Analytics

• JobTxn Document Discount Items Amount
• JobTxn Document Applied Credit Memo Amount
• JobTxn Document Credits Amount
• JobTxn Line Credits Applied On Document
• JobTxn Line Credit Memo Applied To Document
• JobTxn Line Discounts Applied To Document
• JobTxn Line Discounts Applied On Document
• JobTxn Line Payments Applied To Document
• JobTxn Line Payments Applied On Document

Of course we always had the Unapplied Credits - which is a non-linked transaction.

Case Study

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.

Example: 

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