QuickBooks Project

A container, not a label

The clearest way to see the difference is to ask what happens to a transaction when you remove the tag. Take the class off an invoice and you still have the invoice, unchanged, posting to the same accounts. The class was commentary. Take a transaction out of a project and the project itself changes, because the project was never anything except the sum of what is inside it.

That is why projects have a lifecycle and classes do not. Intuit describes the payoff in terms of completion: when a project is done you see total income, expenses and profit margin. "Done" is a state a job can be in. A department is never done, so a class has nothing to report at the end of anything, only over a date range you pick.

The practical consequence for setup is that the two lists behave differently over time. A class list is meant to be short and stable, because it describes the permanent shape of the business. A project list is meant to grow and then go quiet, because it describes work that arrives, gets done, and stops. A business that models jobs as classes ends up with a class list that grows without limit and a usage limit that stops it, which is one of the more common ways of discovering that the two are not interchangeable.

Projects live in the Customer field

The structural fact worth knowing before you plan anything around projects is where a project sits on a transaction, because it is not where a class or a location sits.

Every project belongs to a customer. Intuit's creation flow has you select a customer from the Customer dropdown, and its instruction for assigning an existing transaction is to open it and "select the project in the Customer field". A project therefore occupies the customer slot rather than adding a new one.

That has a consequence people meet by surprise. A class is an extra field, so a transaction can carry a customer and a class independently, and adding classes later disturbs nothing. A project is not an extra field. Putting a transaction into a project means the project is what the transaction points at, so anything that writes the customer on a transaction is also deciding, by omission, that the transaction belongs to no project.

This is the single most important thing to understand about combining projects with any automated feed of sales into QuickBooks. Classes and locations can be added to records written by an integration without touching how the customer is resolved. Projects cannot, because they are competing for the same field.

What the usage limits do and do not cover

Classes and locations share one budget on QuickBooks Online Plus. Intuit's usage-limits article puts the Plus allowance at "40 combined classes and locations", with Advanced offering "Unlimited classes and locations", and notes that "Only active (or invited) users, accounts, classes, locations, and custom fields, count toward the limit in each category."

Projects do not appear in that article as a limited category at all. The limited categories Intuit lists are billable users, non-billable users, classes and locations combined, chart of accounts, custom fields, and QuickBooks Commerce Accounting sales channels. Projects are absent from the list.

That asymmetry is worth planning around rather than treating as trivia, because it points the same direction the conceptual difference does. A segmentation axis is meant to be a small, curated list, and Intuit prices it that way. Work is meant to arrive continuously, and Intuit does not meter it. If the thing you want to track is countable, finite and permanent, it is probably a class or a location. If new instances of it show up every month and eventually finish, it is probably a project, and modelling it as a class is how a business ends up rationing forty slots against work that has no natural ceiling.

Stripe has no project, and no lifecycle to borrow

Nothing in the Stripe data model corresponds to a QuickBooks project. This is a deeper mismatch than the one classes and locations have, and it is worth being precise about why, because the fix that works for those two does not work here.

A class or a location is a single value. Stripe has plenty of places to keep a single value: metadata on a charge, a distinct product or price, a separate Stripe account. Once the value is somewhere on the transaction, translating it into a QuickBooks label is a lookup.

A project is not a value. It is an object with a customer, a start, an end, and a set of member transactions, and Stripe models none of those. Stripe knows about customers, but a Stripe customer is the person or company paying you, whereas a QuickBooks project is a job belonging to that customer. Stripe has no notion of a job at all, and no notion of one finishing. So there is no field to read the project from, and no event that tells QuickBooks a project has ended.

That leaves the association to be made on the QuickBooks side, and it interacts with the Customer field point above. A sale has to name a customer in QuickBooks, and the customer is the fact a payment processor actually knows. The project is not, because the information that would identify one does not exist upstream. So any business that wants processor revenue counted inside project profitability is looking at a deliberate QuickBooks-side step rather than something that arrives on its own, and that is much cheaper to plan at setup than to discover at the end of a job.

Choosing between a project, a class and a location

Three questions separate them cleanly, and they are worth asking in this order.

Does it end? If the thing you are tracking has a completion date after which no more transactions belong to it, it is a project. Renovations, engagements, builds, installations, cases, events. If it never ends, it is a class or a location.

Is it a place? If it is a permanent physical site and every transaction belongs entirely to one of them, it is a location. Locations attach to a whole transaction and cannot vary line by line, which is fine for a place and limiting for anything else.

Is it a way of cutting up the permanent business? Then it is a class. Departments, product lines, funding sources, programs. Classes are the most flexible of the three because they can vary line by line, and the most easily abused for the same reason.

They compose, which is the part worth remembering. A single invoice can belong to a project, carry a location, and have its lines split across classes, and the reports answer three different questions from the same record. What does not work is substituting one for another, because the reports they produce are not answers to the same question with different labels on them.