Duplicate transactions in QuickBooks
Symptom: The same invoice, payment, or bill appears twice or more in QuickBooks after a sync runs.
Why it happens: The most common cause is a team member entering the transaction manually in QuickBooks at the same time Buildertrend is set to push it automatically. The second most common cause is a re-authorization event: if the integration was disconnected and reconnected while transactions were in a pending state, they can push twice. Deleting and recreating a transaction in Buildertrend can also generate a second QuickBooks record if the first one was already synced.
Fix: Identify which copy is the source of truth (always the one Buildertrend created via sync). Void or delete the manual duplicate in QuickBooks. Then establish a firm workflow rule: each transaction type is owned by one system. If invoices originate in Buildertrend, no one touches that transaction in QuickBooks unless the sync failed and they are correcting a specific error.
Change orders not posting or posting twice
Symptom: An approved change order never appeared in QuickBooks, or the original contract amount and the change amount both posted as separate line items, inflating the invoice total.
Why it happens: Buildertrend has a configurable trigger that controls when change orders push to QuickBooks Online. If it is set to sync only after client acceptance and the client has not yet acknowledged the change, the change order waits in the queue without any visible error. The double-posting variant happens when Buildertrend pushed an original invoice, the change order was then approved, and a revised invoice was pushed without voiding the first.
Fix: For stuck change orders: in Buildertrend's accounting settings, locate the change order sync trigger and decide whether it should fire on internal approval or client acceptance, then align it with your actual workflow. For double postings: void the original invoice in QuickBooks and keep the revised version, or use a credit memo to offset the overstatement. Going forward, confirm the trigger setting before approving a change order so you know when it will hit QuickBooks.
Customer portal payments do not match the bank deposit
Symptom: A client paid through the Buildertrend customer portal, but the amount showing in QuickBooks does not match what actually deposited in the bank account. The reconciliation shows an unresolved difference on every portal payment.
Why it happens: Buildertrend records the gross payment the client submitted. The payment processor (credit card or ACH) deducts its merchant fee before sending the net deposit to the bank. QuickBooks receives the gross payment figure; the bank statement shows the net amount. Without a separate entry for the fee, they will never match.
Fix: Record the merchant processing fee as a separate expense each time a portal payment posts, or configure the bank deposit in QuickBooks to show two lines: the full payment received and the fee deducted, netting to the bank deposit amount. This is not a Buildertrend bug; it is a bookkeeping step that must be built into the workflow for every portal payment. If these fees are piling up unrecorded, a cleanup pass through your merchant deposit history will clear the backlog.
Costs landing on the wrong job or cost code
Symptom: Bills or subcontractor costs that belong to one job appear in QuickBooks under a different job, or costs land in a generic overhead account instead of the specific cost code they should hit.
Why it happens: Every Buildertrend cost category must be mapped to a valid QuickBooks item or account. When someone adds a new cost category in Buildertrend without updating the accounting mapping, or when a QuickBooks account is renamed and the reference breaks, costs fall back to a default account or route to the wrong job entirely. This is also a common outcome when two jobs share a similar name and the name-matching algorithm picks the wrong one.
Fix: Open the accounting mapping settings in Buildertrend and audit every cost category. Confirm each one points to a currently named, active QuickBooks account or item. Broken or unmapped entries are usually highlighted. Once the mapping is corrected, manually reclassify any costs that already landed in the wrong place by editing the QuickBooks transaction directly. For recurring misrouting, check that job names in both systems are distinct enough that no ambiguity exists.
Unmapped items blocking specific record types
Symptom: The sync runs without error for most records, but specific invoices or bills consistently fail to push. The sync queue shows a warning or error icon next to those records, and retrying does not clear them.
Why it happens: Buildertrend requires a valid QuickBooks product or service item for every line it is trying to sync. If a line item in Buildertrend references a product or service that does not exist in QuickBooks Online (because it was deleted, deactivated, or was never created), the entire transaction can stall rather than push partially.
Fix: Open the failed record in the sync queue and note the specific item or account name it is trying to match. Search QuickBooks Online for that item. If it was deleted, restore it or create a replacement with the same name and re-map it in Buildertrend. If the item never existed in QuickBooks, create it and then map the corresponding Buildertrend cost category to it. Once the mapping is valid, use the retry function on the failed push.
The connection dropped and re-authorizing did not fix it
Symptom: Nothing is syncing at all. The connection looks active in Buildertrend settings, but nothing moves through the queue and re-authorizing seems to have no effect.
Why it happens: OAuth tokens issued by QuickBooks Online expire on a set cycle. If the token lapses while transactions are queued, they can accumulate in a failed state. Re-authorizing creates a new valid token, but the queued records that failed under the old token still need to be retried. If there is a record with a mapping error at the front of the queue, it will continue blocking everything even after re-authorization.
Fix: After re-authorizing, do not just wait for the sync to resume. Go into the sync queue and look for records in a failed state. Resolve the earliest one first, mapping or naming issues are the most common cause, then retry it. Work forward through the queue until everything is cleared. If the connection drops again within a short period, verify that the QuickBooks Online user whose credentials were used for the connection still has the correct access level.
Customer or job name mismatches creating new records
Symptom: Invoices push to the wrong customer in QuickBooks Online, or a customer who already exists gets a brand-new duplicate record as if they are a first-time client.
Why it happens: Buildertrend and QuickBooks Online match customers and sub-jobs by exact display name, including punctuation, spacing, and capitalization. If the Buildertrend job name is "Smith Residence Phase 2" and QuickBooks has "Smith, John: Phase 2," they do not match and QuickBooks creates a new customer record rather than linking to the existing one.
Fix: Choose one system as the naming source of truth, typically Buildertrend, and update QuickBooks to match exactly. Establish a naming convention before any new job is created and document it for the whole team. Merge any duplicate customer records that were created during the mismatch period using QuickBooks's merge function. Going forward, build the job in one system first, copy the name exactly, then create it in the other system.
Records edited or deleted in one system not updating the other
Symptom: You corrected an invoice amount or voided a bill in QuickBooks, but Buildertrend still shows the original figure. Or you deleted a record in Buildertrend and the entry in QuickBooks is still there.
Why it happens: The Buildertrend-to-QuickBooks Online sync is primarily one-directional for most record types: data flows from Buildertrend into QuickBooks, not back. Edits made directly in QuickBooks do not automatically update Buildertrend. Deletions in Buildertrend do not automatically void or delete the corresponding QuickBooks entry.
Fix: Corrections should always start in Buildertrend when possible, then re-sync. If you have already corrected something directly in QuickBooks, you need to decide whether to also update Buildertrend to match, or accept that the two systems will show different figures for that record. Document this as an exception. For voided or deleted transactions, manually void the corresponding QuickBooks entry if Buildertrend did not trigger that action automatically.
Tax or rounding discrepancies on synced invoices
Symptom: Invoice totals in Buildertrend and QuickBooks are off by small amounts. The difference is usually a few cents to a few dollars, and it appears consistently across multiple invoices.
Why it happens: Sales tax and rounding are calculated independently in each system. If Buildertrend calculates sales tax on a line-by-line basis and QuickBooks applies it to the invoice total, the rounding method can produce a small difference. Similarly, if tax rates or taxability rules differ between the two systems, the totals will diverge every time a taxable item is included.
Fix: Align the tax settings in both systems so taxability, rates, and rounding methods match. Check whether Buildertrend is configured to push the tax as a separate line item or embed it in the line total, and verify that QuickBooks is expecting the same structure. Ongoing penny differences almost always mean the tax configuration diverged at some point and needs to be reconciled.
