How do I connect QuickBooks vendor bills to a Loopfour workflow?

Loopfour's QuickBooks integration creates a bill with a single, unconditional API call — there's no upsert-by-document-number the way there is for invoices, so a blind retry after a timeout creates a second bill. Loopfour can also create the vendor first if it doesn't already exist; a bill doesn't require a pre-existing vendor record.

By Zuny Fester, Head of Operations and Marketing

Reviewed by Zuny Fester

Published September 14, 2026Last reviewed September 14, 2026Editorial policy

Part of the finance integrations guide.

What gets created	A QuickBooks Online Bill (createBill), tied to a vendor via VendorRef
Matching behavior	None — createBill is an unconditional POST /bill. QuickBooks' DocNumber-based upsert helper only covers Invoice and JournalEntry, not Bill
Vendor prerequisite	None — createVendor exists in Loopfour's QuickBooks integration, so the workflow can create the vendor first if needed
Read-back options	getBill, updateBill, and listBills all exist, but none of them look up a bill by DocNumber directly

What the connection needs before the first bill syncs

A vendor bill in QuickBooks Online is tied to a vendor record via VendorRef — you can't create a bill without one. Unlike some of the other objects in Loopfour's QuickBooks integration, this isn't a hard prerequisite the workflow has to satisfy externally: createVendor exists as its own action, so a workflow can create the vendor first (if it doesn't already exist) and then create the bill against it, all within the same run.

Why a retry can create a duplicate bill

createBill is a plain, unconditional POST to /bill — every call creates a new bill record, full stop. That's a real difference from how Loopfour handles QuickBooks invoices and journal entries, which do have a DocNumber-based upsert helper purpose-built to make a retry safe: probe for an existing record by DocNumber first, then create or update accordingly. That helper only covers the Invoice and JournalEntry entities; there's no equivalent for Bill. A workflow that retries a bill-creation call after a timeout, assuming the same safety net applies, will get two bills for the same vendor invoice.

What actually protects against a duplicate here

getBill, updateBill, and listBills all exist in Loopfour's QuickBooks integration — a bill isn't write-only. But listBills filters on vendor, balance, and transaction/due dates, not DocNumber, so there's no direct "does this DocNumber already exist" lookup built in for bills the way there is for invoices. The workflow itself has to own idempotency: track the source bill's identifier externally (in its own state, not QuickBooks'), and check that before calling createBill again — or query listBills by vendor and date range as an approximate check — rather than assuming a retry is automatically safe.

Where the bill shows up afterward

QuickBooks Online splits bills into a For Review tab (for bills that arrived through an upload or the QuickBooks Business Network) and an Unpaid tab (for bills entered directly, which QuickBooks treats as needing no further review). A bill created through a Loopfour workflow lands in the Unpaid tab — it won't sit in For Review waiting on a manual confirmation step.

Next step

Map the finance workflow with the most exposure and prove the automation path.

Bring the invoice, contract, payment reconciliation, or customer finance workflow you have to defend at audit. Loopfour can map the trigger, controls, integrations, and approval loop.

Book a workflow review

Worked example

A $2,150 bill that duplicates on a blind retry

A workflow calls createBill for vendor invoice #INV-88214, setting DocNumber to that number for reference. QuickBooks accepts the bill and returns success, but the response times out on Loopfour's side before the confirmation is received. The workflow's retry logic, assuming bill creation behaves like invoice creation, calls createBill again with the same VendorRef and DocNumber. Because createBill has no dedup check, QuickBooks Online now shows two $2,150 bills for the same vendor, both with DocNumber INV-88214 — DocNumber isn't unique-constrained the way it functionally is for invoices, so QuickBooks accepts the second one without complaint. The fix: before the retry, the workflow checks its own record of whether INV-88214 was already sent (or calls listBills filtered to that vendor and date) rather than assuming the first attempt failed just because the response didn't arrive.

Frequently Asked Questions

It can — createVendor exists in Loopfour's QuickBooks integration, so a workflow can create the vendor before creating the bill. The vendor doesn't have to pre-exist the way it does for some other integrations in this matrix.

Nothing prevents it — unlike Invoice or JournalEntry, Bill has no DocNumber-based upsert helper, so QuickBooks will happily create two separate bills that both carry the same DocNumber. Treat DocNumber on a bill as a reference field, not a uniqueness guarantee.

No — bills entered directly, rather than uploaded or received through the QuickBooks Business Network, land in the Unpaid tab, which QuickBooks treats as not needing further review. That's a separate fact from bill creation's lack of dedup, and both are true at once.

Sources

Diagnostic

How do I reconcile a phantom AP liability from a broken Bill.com sync?

Compare open bills in your AP aging against actual disbursements on the bank statement. A phantom liability shows up as a bill still open in AP with a matching payment already visible on the bank side, which means the payment posted in Bill.com but its corresponding payment record never synced back to the accounting system, leaving the original bill looking unpaid.

Topic

AP & Invoice Processing

Accounts payable and invoice processing is the set of steps a vendor bill goes through between arriving at a company and turning into a payment: capturing what the vendor sent, checking it against wha…

Diagnostic

What causes a three-way match failure between the PO, receipt, and invoice?

A three-way match compares the PO, the receipt (what was actually delivered), and the invoice on quantity, price, and charges. A failure means one of those three disagrees beyond tolerance — usually because the invoice bills a quantity that isn't fully receipted yet, the unit price differs from the PO, or the invoice adds a charge, like freight, the PO never included.