QuickBooks Class Tracking

Class, location, or project: three mechanisms people reach for interchangeably

Classes, locations and projects all promise to break the business into parts. Picking the wrong one means rebuilding your reporting later, so it is worth thirty seconds of thought up front.

A class is the general-purpose segment. Intuit names departments and product lines as the examples, and then opens it up to "any other meaningful segments in your business."

A location is for place. Intuit describes it this way: "Location tracking is used to categorize data from different locations, offices, regions, outlets, or departments of the same company." When place is the question, Intuit points you there directly: "If you do business in multiple locations, you can use location tracking instead. This is a more specific way of tracking your sales, purchases, and profitability by business location."

A project is for job costing. Intuit is brief about it: "use the Projects feature to track your job costs and income."

A rule that holds up in practice: if the segment is a what, meaning a product line, a department, a revenue stream, use a class. If it is a where, use a location. If it is a discrete piece of work with a start and an end, use a project. Class tracking and location tracking both require Plus or Advanced.

The reason the distinction earns its space is that classes and locations are separate axes and you can run both at once. Businesses that force one to do the other job end up with class lists like "Retail Chicago" and "Retail Denver", multiplying two dimensions into a single flat list that grows as the product of both instead of the sum.

One class per transaction, or one per line

When you turn class tracking on, QuickBooks asks how granular you want to be. The Assigned classes setting offers two options: "One to entire transaction" or "One to each row in transaction".

Intuit describes the simpler one: "You have the option to assign one class to an entire invoice, receipt, or any other customer transaction. This saves you time if you don’t need to track each product you sell by class." The other option adds a Class column to the transaction so each line carries its own.

Which is right depends on one question: can a single transaction span more than one segment? If every invoice belongs wholly to one product line, per transaction is faster and there is less to get wrong. If one invoice can carry a subscription line and a services line that belong to different segments, per transaction forces you to pick one of them and silently misattribute the rest.

For single-product orders this is a genuine time saver. For anyone with mixed carts or bundled invoices, per row is the only setting that produces correct segment reporting.

QuickBooks offers a safeguard worth enabling at the same time: "Warn me when a transaction isn’t assigned a class." Unclassified transactions are the main failure mode of class tracking, because they do not raise an error. They simply fall out of segment reports while remaining in the totals. That produces the most confusing version of the problem, where your class report and your profit and loss disagree and nothing on either one explains the gap.

Keeping the class list small enough to be useful

Intuit issues its own warning about this, and it is the most practical line in their documentation on the feature: "Too many classes can be time consuming to work with. And the more straightforward your classes are, the easier it is to understand your reports."

A class list is a reporting dimension, and a dimension is useful when it has few enough values that a person can hold them all in mind at once. Five product lines is a dimension. Sixty is a filing cabinet, and nobody reads a sixty-row profit and loss by segment.

The usual sign that a list has gone wrong is compounding: class names that encode two things at once, like a channel plus a region. That is two dimensions crammed into one, and QuickBooks has a second dimension available for exactly that purpose.

A question worth answering before you create a single class: what do you want the profit and loss to tell you that it cannot tell you today? Build the list backwards from that answer, and stop when it does.

Stripe has no class field

This is the part that catches out businesses running on Stripe.

A class is a QuickBooks construct. Stripe objects carry their own dimensions: a product, a price, and whatever metadata you choose to attach. None of those is a class, and nothing in Stripe’s data model corresponds to one. When a Stripe charge becomes a QuickBooks transaction, no class comes with it. The class has to be assigned on the QuickBooks side, by whoever or whatever writes the record.

Two things follow. The first is that the segments you want to report on have to exist as something identifiable in Stripe before they can be translated into anything on the QuickBooks side. A product ID or a metadata key is a durable handle. A pattern in a free-text description is not, and it will break the first time someone edits the wording.

The second is sequencing. If class tracking is switched off in QuickBooks, there is nothing to assign to, so enabling it and designing the class list comes before any question of how Stripe data gets routed. Turn it on first, keep the list short, and decide what identifies each segment on the Stripe side.