Case study: How a plumbing contractor moved from QuickBooks to Sage Intacct Construction

For a plumbing company, a part number carries a lot of information: the fitting, the size, the job it should bill to, and what it cost. Our client, Ackerman, tracked inventory meticulously, with strict item IDs and part numbers, and came to us wanting that detail and the accounting in one place. We moved Ackerman from QuickBooks to Sage Intacct Construction, and this case study walks through what that work involved, plus when a move like it makes sense for a plumbing business.

If your plumbing business runs fine on basic bookkeeping, QuickBooks may still fit. If job and material questions keep getting answered from exports and side spreadsheets, you are in Ackerman territory, and the migration becomes a design project: deciding how jobs, materials, and costs should be organized before anything gets imported.

For this case study we sat down with Tina Rehberg, our Senior Sage Intacct Consultant, who spent over 30 years in construction finance, controller to CFO, before moving into consulting. We also asked Troy Guevara, our Construction Technologist, and Audra Speth, our Customer Success Manager, where moves like this succeed or get harder than expected.

Ackerman was a plumbing implementation, moving from QuickBooks to Sage Intacct Construction. This case study provides a practical lesson on the shape of the implementation work rather than a numbered outcome.

Ackerman’s move was bigger than a chart-of-accounts conversion

The first decision is using the right Sage product. Troy told us, “Construction companies researching Intacct need to know they want Sage Intacct Construction, not the generic version.” For a contractor, that distinction matters because the construction version is built around job costing, project profit and loss reports, cost codes, compliance, and project accounting needs.

Moving the chart of accounts was the easy part. Ackerman also had to bring over detailed plumbing inventory records, and those records carried meaning beyond accounting labels.

For a plumbing contractor, an item ID or part number may be how the team separates similar materials, finds the right record, and ties a cost back to a job. If the new system receives duplicate items, vague descriptions, or inconsistent part numbers, the report may still need manual interpretation after the move.

Strict plumbing inventory made the data model matter

Inventory detail changes the migration conversation because item records affect how costs are entered, grouped, and reported. If a plumbing contractor has strict part-number rules, the implementation team needs to understand those rules before deciding what to import, what to clean up, and what to reorganize.

In the new structure, a single material cost needs the right item, project, cost code, and cost type behind it. If any one of those is wrong or missing, the job-cost report can show a total that looks right while the detail underneath cannot be trusted.

That is why finance and operations both need a voice in the design. Finance knows which reports must reconcile. Operations knows how the team names parts, talks about jobs, and finds materials. The implementer can guide the model, but the contractor has to decide how it wants jobs, materials, and costs entered and reported going forward.

Moving from QuickBooks lists to job-cost reporting structure

The biggest conceptual shift for many QuickBooks users is dimensional accounting. A dimension is a reporting tag on a transaction, such as project, location, cost code, cost type, customer, or vendor, that lets finance analyze work without creating a separate general ledger account for every reporting need.

Tina’s answer on the hardest concept was direct: “Dimensions, by far.”

She contrasted that with a Sage 300 CRE migration, where the client often already has a prefix, base account, and sub-account format that maps more naturally into Intacct dimensions. A QuickBooks team usually knows customers and vendors well. The bigger step is expanding that into projects, locations, cost codes, cost types, and inventory detail, and that is where the implementation becomes translation work.

Tina told us, “I let the client explain their world first so I hear their language, and then I adapt my language to theirs.” That matters in specialty trades. One team’s “task” may be another team’s activity or cost code. A part number may be the real language of the field, while an item description may be the language of accounting. The model has to account for both.

What the new structure had to carry

Once each transaction carries its job, project, cost code, cost type, and a clean item record, the report changes. Instead of asking only which account a cost hit, the controller can see the job, cost, and item context behind it.

Troy’s warning fits this kind of move. When we asked him about common early implementation mistakes, he said, “Trying to keep their old ways.” A migration can carry old confusion into a new system if the team treats every existing habit as a requirement.

Audra added the customer success view we see after go-live. She told us, “We don’t think, ‘We’ve done a hundred of these, let’s just duplicate.’ Each company has something unique, and we’ll slow down and look at each one.” For a plumbing contractor with strict inventory detail, taking a slower look avoids building a model that looks tidy in setup and breaks down in daily use.

What a similar contractor should do next

Ackerman’s case is useful because it shows the work that often determines whether a QuickBooks-to-Sage Intacct Construction move becomes usable: clean item records, clear part-number rules, a dimension model finance understands, and a willingness to redesign workarounds that were built around the old system.

If your plumbing business does not need detailed job-cost, inventory, or project reporting, staying in QuickBooks for now may be the more practical choice. If your team is already rebuilding spreadsheets to answer job and material questions, the better next step is to inspect your records and decide what the new structure needs to carry.

The data decisions matter as much as the system decision. The contractor has to define how jobs, materials, and costs should be entered. The implementation team can then build around that structure instead of guessing from a messy export.