The five 3180 message variants — match yours to the right fix:

The Sales Tax Payable rule — specific to 3180: The Sales Tax Payable account must be mapped exclusively to the sales tax row in POS Preferences → Financial → Accounts. If it appears in any other row (as the account for a different item or transaction type), or if a payout was made directly to the Sales Tax Payable account, QB Financial rejects the posting with Status 3180. The Sales Tax Payable account is reserved only for sales tax transactions and cannot be shared or repurposed.

Sales Tax Item Not Linked to a Vendor

Most common cause of "Sales tax detail line must have a vendor" — QB requires every sales tax item to be associated with a specific vendor (the tax agency you remit to). Without this link, QB cannot create the correct tax liability posting and fails with 3180. Check QB Financial → Lists → Item List → Include Inactive → sort by Type → verify every Sales Tax item has a Tax Agency field filled in.

Wrong Account Type in POS Item Mapping

The account mapped to a POS item is the wrong type for that transaction — for example, an income account mapped where an expense account is required, or the Sales Tax Payable account used for a non-tax item. QB Financial rejects the posting because the account type does not match the transaction structure, producing "The posting account is invalid."

Damaged or Wrong-Type Payment Item

A payment item in the POS item list is corrupted or set to an incorrect item type. During Financial Exchange, QB cannot match the damaged item to a valid QB account and fails with 3180 plus error code 140108. The fix requires renaming the item with an OLD prefix to force QB to create a fresh replacement, then merging the resulting duplicate in QB Financial.

Payout Created Using Sales Tax Payable Account

A cash payout was recorded in POS using the Sales Tax Payable account as the target account. QB Financial does not allow the Sales Tax Payable account to be used for payouts — it is reserved exclusively for tax liability entries. The receipt with this payout produces 3180 every time the Financial Exchange runs until the payout is reversed and recreated with an appropriate account.

Sales Tax Payable Mapped to Multiple Rows

The Sales Tax Payable account appears in more than one row in POS Preferences → Financial → Accounts (e.g., mapped for sales tax AND also mapped for another account type). QB requires the Sales Tax Payable account to appear only in the Sales Tax row — any other usage produces 3180 on the affected transactions.

Employee or Vendor Name Duplicate Between POS and QB

A duplicate name exists between POS and QB — for example, the same name exists as both a Customer and Vendor in QB. When POS tries to sync this record, the exchange fails with 3180 because QB cannot determine which record type to use for the transaction. Check QB Customer and Vendor lists for duplicate names across categories.

METHOD 1 Link Sales Tax Items to Vendors + Verify Account Mapping Variants 1 and 2 — sales tax vendor missing or posting account wrong

METHOD 2 Repair Damaged Payment Items — The Rename and Merge Technique Variant 4 — "140108 Payment Item Lookup Error"

This technique creates a fresh replacement item alongside the damaged one, then merges them — preserving transaction history while fixing the corruption.

METHOD 3 Reverse and Recreate the Payout with a Correct Account Variant 3 — payout to Sales Tax Payable account

METHOD 4 Rename and Recreate Payment Methods (Cash, Cheque, etc.) Posting account invalid for standard payment methods

Why must every sales tax item have a vendor in QuickBooks?

QuickBooks models sales tax as a liability owed to a specific government or tax authority. When you collect sales tax from a customer, QB creates a credit to the Sales Tax Payable account and simultaneously tracks which vendor (tax authority) that liability belongs to — so that when you remit the tax, QB knows which authority received the payment and can mark the liability as cleared. If a sales tax item has no vendor attached, QB has no way to create this complete liability record and rejects the transaction with "Sales tax detail line must have a vendor" (Status 3180). Every sales tax item in QB must identify its corresponding tax agency vendor.

Why does the rename-and-merge technique work for damaged payment items?

When a POS payment item becomes corrupted, its internal data structure is broken — but QB POS still holds a reference to this item's unique ID. Deleting the item outright would leave POS with a dangling reference and could cause data loss. The rename-and-merge technique works around this by: (1) renaming the broken item with an OLD prefix so POS no longer finds it by its original name; (2) running the Financial Exchange so POS creates a brand new, uncorrupted item with the correct name; (3) merging the old item into the new one by giving the old item the same name as the new one and clicking Yes to merge. QB transfers the transaction history from the old item to the new one, preserving all records while removing the corrupted data structure.

Are sales receipts that failed with 3180 lost?

No. Sales receipts that failed to exchange due to Error 3180 remain queued in POS with a "Not Posted" status. They can be viewed in POS → Sales History → add the QuickBooks Status column to identify them. Once you fix the underlying cause (sales tax vendor, posting account, or payment item), running the Financial Exchange again will attempt to post all pending receipts. Check the Activity Log afterwards to confirm all previously failing receipts have been successfully posted.