Reporting

Classes vs Locations vs Customer: how to choose the right dimension

QuickBooks Desktop gives you a few levers for segmentation. Use the right one for the job, and do not mix dimensions inside one field.

A one stop solution for multi-user QuickBooks Desktop on a managed Windows Server environment.

The problem you are trying to solve

Most reporting disasters are not “QuickBooks is weak.” They are “we used the wrong list for the wrong meaning.” Before you change anything, pick the one question you need to answer consistently:

  • Do you need profitability by branch or department, such as a P&L by class?
  • Do you need balances and history by customer, and maybe by job or project under that customer?
  • Do you need a geographic view, such as city or region, without breaking customer statements?

Classes are for one category only

Intuit’s guidance is specific: set up classes based on the reporting you want, and use classes for one category only. They even give the example of using classes for locations like Uptown, Midtown, Downtown.

  • Use classes for: departments, branches, locations, product lines, or profit centres, but pick one.
  • Do not use classes for: both departments and locations at the same time. That turns reporting into a matrix QuickBooks Desktop cannot represent cleanly.

If you want P&L by class to be meaningful, your staff must consistently assign a class on transactions. Intuit provides an option to prompt users to assign classes.

Customer and Job is for the customer hierarchy

Customer:Job is the right tool when you need statements, collections, and A/R to remain customer-specific. A common structure is: customer as the real customer, then jobs for projects, branches, or locations under that customer, depending on your business.

  • Use Customer and Job when the primary need is customer balance, collections, and customer-level reporting.
  • Jobs can represent projects or sub-accounts that still roll up to the customer.
  • If your goal is geographic grouping across many customers, consider a separate approach (for example, customer types or consistent naming), but do not force geography into classes and jobs at the same time.

A clean decision rule

  • Need P&L by branch or department? Use classes for that one category, and keep it stable.
  • Need customer statements and A/R aging by customer? Keep Customer:Job clean and use jobs only when you genuinely need sub-tracking under that customer.
  • Need both? Choose which one is more important. If both are critical, you need process discipline and a clear policy so the same transaction is not overloaded with multiple meanings.

If you mix dimensions, you will eventually get a P&L by class that does not match what management thinks it means.

References

Related reading: How to use QuickBooks classes properly.

Want this implemented correctly?

We design the server, lock down access, and keep the environment stable. If you want a predictable QuickBooks Desktop setup, talk to us.

Windows desktop stacks we run every day

We build and manage Windows Server environments for serious accounting stacks, including QuickBooks Desktop Enterprise, Sage, Tally, Peachtree, Microsoft Office, SQL Server, OneDrive, Google Drive, and Outlook.

QuickBooks Desktop Enterprise Sage desktop accounting Tally Peachtree by Sage Microsoft ecosystem Microsoft Office apps Microsoft SQL Server OneDrive for Business Google Drive Outlook email
Chat on WhatsApp