Adding Invoice Lines via Web Connector Sync Fails With Error 320

When a custom integration pushes a new invoice line from an external database back into QuickBooks Desktop, the sync can fail with QuickBooks error 320 and a message stating that a specified object cannot be found. The issue surfaces in two-way sync setups where invoices flow between QuickBooks and a separate database, and it specifically affects attempts to append new line items to invoices that already exist in QuickBooks.

How the Problem Surfaces

In a typical scenario, an invoice has already been synced from QuickBooks into the external database. The sync configuration correctly handles bidirectional updates for existing records. The trouble begins when a user adds a new line item entry in the external database’s invoice-line table and expects the Web Connector to push that new line into the corresponding QuickBooks invoice.

Instead of syncing, the operation fails. The error log records error number 320 alongside a message indicating that an object referenced in the request — appearing as a value in the transaction line identifier field — cannot be found in QuickBooks. That identifier field is meant to tell QuickBooks which specific line on the invoice is being modified, and the value being sent does not correspond to any existing line on the QuickBooks side.

If the identifier field is left blank to avoid the lookup problem, the sync fails differently — this time with a parsing error, because QuickBooks expects a value in that field and rejects the empty request outright.

Why the Error Occurs

The root cause is a misunderstanding of how QuickBooks Desktop distinguishes between modifying an existing line and adding a brand-new one during an invoice modification request.

Every line item on a QuickBooks invoice carries a unique transaction line identifier assigned by QuickBooks itself. When you send a modification request to update an existing invoice, QuickBooks uses those identifiers to match each line in your request to the corresponding line already stored in the company file. If you send an identifier that QuickBooks does not recognize — because the line was created externally and never assigned a valid QuickBooks identifier — QuickBooks reports that it cannot find the object and returns error 320.

Leaving the field blank is equally ineffective because the modification request format requires a valid identifier for every line element. An empty value violates the expected structure and triggers a parse failure before QuickBooks even attempts to process the individual lines.

The Working Solution

The accepted fix is straightforward: when adding a new line to an existing invoice through a Web Connector integration, set the transaction line identifier for each new line to -1.

That value is a special signal in the QuickBooks modification framework. It tells QuickBooks, “this line does not exist yet — create it as a new line on this invoice.” QuickBooks interprets the -1 as an instruction to append rather than update, assigns the new line its own internal identifier, and adds it to the invoice.

For a concrete example, consider an invoice that already has three lines with identifiers A, B, and C. To append a fourth line, the modification request should include the three existing identifiers unchanged — A, B, and C — so QuickBooks knows those lines are staying as they are, followed by a new entry with -1 as its identifier along with the item, quantity, amount, and other details for the new line. QuickBooks processes the existing lines as no-ops (they are present but unchanged) and creates the new line from the -1 entry.

Removing Lines With the Same Approach

The same identifier mechanism also governs line deletion. To remove a specific line from an invoice, the modification request simply omits that line’s identifier entirely. Using the same A, B, C example, sending only identifiers A and C in the modification request causes QuickBooks to drop line B from the invoice. The absence of a previously existing identifier signals deletion.

Avoiding the Pitfall Going Forward

Any integration layer that constructs invoice modification requests needs to handle the identifier field correctly for all three operations: existing lines retain their original QuickBooks-assigned identifiers, new lines receive -1, and deleted lines are excluded from the request entirely. Mixing these up — sending an external database’s internal identifier where QuickBooks expects its own, or sending -1 for a line that already exists — will continue to produce sync failures.