QuickBooks Web Connector Error 3140: Misread "Term" Reference Trips Up Invoice Imports
QuickBooks Web Connector error 3140 rejects invoice imports when developers mistake a missing payment-terms reference for a customer-name mismatch between two portal sources.
When a QuickBooks Desktop user attempted to import customers, vendors, and invoices from two separate web portals into a single company file using the Web Connector, the second portal’s invoice imports began failing with error 3140. The error text flagged an invalid reference, and the user initially concluded the problem was a customer-name mismatch — because the customer name in the incoming data appeared to match what already existed in QuickBooks. As it turned out, the customer name was never the issue.
The Setup and the Failure
The user had two web portals operating on different domains and wanted both feeding into one QuickBooks Desktop company file. The approach was to generate two separate QWC (QuickBooks Web Connector) configuration files — one for each portal — and run them independently through the Web Connector. Clients and vendors imported without incident. Invoices, however, were a different story.
When invoice imports ran for the second portal, QuickBooks rejected them with the following message:
3140: There is an invalid reference to QuickBooks Term “Client, Test” in the Invoice. QuickBooks error message: Invalid argument. The specified record does not exist in the list.
The user noticed that the name “Client, Test” appeared in the XML payload and matched the customer name already in QuickBooks. From that, they reasoned the error must be related to how the customer was referenced — and that the matching was somehow failing despite the names being identical.
Where the Diagnosis Went Wrong
The accepted community answer pinpointed the misread. The error message is not referencing the customer at all. It is referencing a payment terms entry — and the keyword in the error is “Term,” not “Customer” or “Name.”
In QuickBooks, payment terms are the billing-schedule records applied to invoices — items like “Net 30,” “Net 15,” or “Due on Receipt.” They live in a separate list from customers and vendors. The error message was telling the user that QuickBooks could not find a terms record called “Client, Test” in its Terms list, because no such terms entry existed. The invoice XML was sending a customer name where QuickBooks expected a terms name, so the lookup failed.
What the XML Was Actually Doing
The invoice XML payload contained multiple FullName elements. One was intended to identify the customer. Another was being mapped into the terms reference — the TermRef FullName field — but it carried the value “Client, Test,” which is a customer name, not a payment-terms name. QuickBooks searched its Terms list for that value, came up empty, and returned error 3140 with the “specified record does not exist in the list” detail.
This is an easy trap. When XML payloads reuse the same field name (FullName) across different contexts — customer, terms, class, and so on — a developer who copies values between elements or uses a single data source to populate multiple fields can inadvertently push a customer name into a terms slot. QuickBooks does not infer intent; it reads the field position and looks up the value in the corresponding list.
The Fix
The solution is to correct the XML so the terms reference field contains a valid payment-terms name that already exists in the QuickBooks company file’s Terms list. Specifically, the TermRef FullName element should carry a value like “Net 30” or “Due on Receipt” — whatever terms record is actually set up in QuickBooks — rather than the customer name.
If the portal’s data does not include a terms field, the developer has two options: send a known terms name that exists in QuickBooks, or omit the terms reference entirely and let QuickBooks apply its default payment terms for that customer. What will not work is sending a customer name and expecting QuickBooks to interpret it as terms.
Broader Takeaway for Multi-Source Imports
Running two QWC files against one company file is a supported configuration, and the failure here was not caused by having multiple connectors. The problem was purely a field-mapping error in the invoice XML. Each FullName element in a QuickBooks XML request is context-sensitive: its meaning depends on which parent element it sits inside. A FullName inside a CustomerRef block identifies a customer. A FullName inside a TermRef block identifies a payment-terms record. Confusing the two produces error 3140 — and the error text, read carefully, always names the list where the lookup failed.
For developers building QuickBooks integrations, the discipline is to read error messages literally. When QuickBooks says “Term,” it means the Terms list — not the customer, not the vendor, and not the item. The word preceding the quoted value in a 3140 error identifies exactly which list QuickBooks searched, and that is the list where the missing record needs to be created or the reference needs to be corrected.