The product catalog is the real work in connecting QuickBooks

Every line on an estimate has to exist as a product on both sides. That is the requirement underneath any CRM-to-accounting connection, and it is the reason the technical setup takes an afternoon while the project takes a month.

JobNimbus states the rule plainly: with its QuickBooks integration enabled, custom products in work orders, material orders, estimates and invoices are no longer allowed. We have written about what that connection does and does not carry elsewhere. This post is about the work that comes first.

Count your freehand lines

Export a season of estimates. Sort every line into two piles: picked from a list, or typed by hand.

The second pile is your project.

Owners guess this number low, consistently. The lines that get typed freehand are the memorable exceptions, so they feel rare, and the export usually finds a long tail nobody had in mind: a charge invented for one difficult customer, a material described three different ways by three estimators, a note that became a line because there was nowhere else to put it. Ten minutes with a spreadsheet replaces the guess with a count, and the count is what tells you whether connecting your books is a weekend or a quarter.

Thirty-two characters

The naming limits are where a tidy plan meets reality. Product names cap at 32 characters for QuickBooks Desktop and 100 for QuickBooks Online, and a colon is not permitted in a name at all.

One hundred is generous. Thirty-two is not.

Count how your team currently describes a shingle: manufacturer, product line, color, bundle count. That is comfortably past thirty-two before anyone has been unreasonable. So a Desktop shop has to invent an abbreviation scheme, and the scheme has to be decided once, by somebody, and not improvised by whoever creates the next product. Otherwise you end up with three abbreviations of the same material, which is the exact problem the catalog was supposed to solve.

Write the convention down before anybody starts. Manufacturer first or product line first, abbreviations fixed in a list, color at the end. It is a boring twenty minutes that saves an argument in month three.

The one-off problem

Some charges genuinely happen once. A tree that has to be worked around, a homeowner who wants something unusual, a concession made to close a job.

Under the old habit those got typed as a line and forgotten. Under a shared catalog they need a home, and the wrong answer is to create a product for each, because a year later the list has four hundred entries and nobody can find anything.

The workable pattern is a small set of deliberately generic lines with the specifics living in the description: one for site access work, one for a customer-requested extra, one for a concession. The line is the accounting category. The description is what actually happened. That keeps the catalog stable while leaving the estimate readable, and it keeps your accountant from receiving a chart of products that grows without limit.

Decide this before the migration rather than during it, because retrofitting the pattern means editing historical records that have already crossed into your books.

Who gets to create a product

This is the operational question that decides whether the whole thing works.

If creating a product needs a permission that only the owner has, and the owner is on roofs, an estimator hitting a missing line at four in the afternoon has three options: wait, use something close enough, or write something vague. Two of those corrupt the data the integration was installed to protect.

Pick somebody who is at a desk during quoting hours. Give them the naming convention. Make the request path something faster than a phone call, because the alternative is not a delayed product, it is a wrong line item.

What good looks like afterwards

A catalog that has settled has a shape worth aiming at directly.

New products get created a few times a month rather than a few times a day. The same material has one entry and one name. An estimator can find a line by typing the first three characters of it, which is a real test you can run by asking one to try. And your accountant can look at a product report and recognize the business, which is the whole point of the two systems agreeing in the first place.

That state does not arrive on its own. It arrives because somebody did the counting, wrote the convention and named an owner, in that order, before the connection was switched on.

When this is somebody else's problem

Worth saying plainly: a catalog is a genuinely useful thing to own, and the discipline is worth having whether or not you ever connect anything.

The reason it feels like a chore here is that the shape of it is being set by the older of two databases you did not design. Thirty-two characters is not a fact about roofing. It is a fact about a product built in the nineties, reaching your estimator's afternoon in 2026.

Where a company holds its own pricing, materials and jobs in one place, the catalog is still a catalog, and it still needs a convention. What it does not need is an abbreviation scheme inherited from somebody else's field length, or a rule that a line item cannot exist until it has been created in a second system. Those constraints are the price of joining two products, and they are worth paying when joining two products is the right answer.