QuickBooks Online n8n integrationAutomate QuickBooks Online with n8n.

A vendor bill lands in QuickBooks with its line items attached, and the money sits on the accounts payable side of the books.

• For Vendor Name or ID: the vendor the bill belongs to, picked from the dropdown or set with an expression such as {{ $json.VendorRef }}.
• Line: one entry per charge, with Amount, Description and a Detail Type of either Account-Based Expense Line Detail or Item-Based Expense Line Detail.
• Additional Fields: where Due Date, Transaction Date and Total Amount live.

Removing a bill takes one value and gives no second chance, so this operation usually sits behind a condition rather than at the front of a workflow.

• Bill ID: the identifier of the bill to delete, not the vendor name and not the document number. It comes from a Get Many step or from whatever created the bill, typically as {{ $json.Id }}.

One bill comes back in full, with its lines, its balance and its dates, so the workflow can decide what to do with it.

• Bill ID: the identifier of the bill to retrieve. Store it when the bill is created and the lookup later costs nothing.

Bills come back as a list of items, one per bill, which every node after this one processes in turn.

• Return All: on, n8n walks the API pages until every bill is in hand. Off, Limit caps how many come back.
• Query: a condition that narrows the selection before anything leaves QuickBooks, for example WHERE Metadata.LastUpdatedTime > '2021-01-01'.

Editing an existing bill means naming it and then naming what changes. Only the fields you add are sent, the rest of the record stays as it is.

• Bill ID: the bill being modified.
• Update Fields: the collection holding Due Date, Transaction Date, Sales Term and the Accounts Payable Account the bill is credited to.

New customer records start with a single mandatory value and grow from there. QuickBooks returns the created record, so the identifier is available to the next node right away.

• Display Name: the name the customer appears under, and the only required field.
• Additional Fields: fourteen optional values including Company Name, Primary Email Address, Primary Phone, Billing Address, Taxable and Preferred Delivery Method, which accepts Print, Email or None.

When a workflow already knows which customer it is dealing with, this pulls the current record: balance, contact details, whether the account is still active.

• Customer ID: the QuickBooks identifier, not the display name. A Get Many step is the usual way to turn a name into an ID first.

The whole customer book, or a slice of it, arrives as items you can loop over, compare or export.

• Return All: enable it for a complete export, leave it off and Limit decides the ceiling.
• Query: the filter condition, handy when only recently modified customers matter.

Keeping customer data current is a two part instruction: which record, and which values replace what is there.

• Customer ID: the record to modify.
• Update Fields: fourteen values are available, among them Primary Email Address, Billing Address, Company Name, Taxable and Active, which is how a customer gets switched off without being removed.

Employees are added without any mandatory field, which means an empty node would create an empty record. Fill in the name fields at minimum.

• Given Name and Family Name: the first and last name of the employee.
• Additional Fields: seven further values, including Display Name, Primary Phone, Print-On-Check Name, Social Security Number and Billable Time.

Reading a single employee record returns what QuickBooks holds on that person, including whether they are still flagged as active.

• Employee ID: the identifier of the employee to retrieve, usually carried over from an earlier list step.

Every employee on file comes back as items, which is the starting point for anything that has to run per person.

• Return All: turn it on to get the full roster rather than the first page.
• Limit: the ceiling when Return All stays off.
• Query: narrows the list, for instance to records modified since a given date.

Changes to an employee record go through the same pattern as customers: an identifier, then the fields being rewritten.

• Employee ID: whose record is being edited.
• Update Fields: seven values, notably Active, Billable Time, Primary Phone and Billing Address.

Quotes take shape here. The estimate is written against a customer, priced through its lines, and returned with an identifier you can send or update later.

• For Customer Name or ID: who the quote is for, from the list or from an expression.
• Line: each row carries Amount, Description, an Item Name or ID and a Detail Type of Sales Item Line Detail.
• Billing Email and Customer Memo: the address the quote goes to, and the note the customer reads on it.

Dropping an estimate is final, so it belongs at the end of a branch that has already decided the quote is dead.

• Estimate ID: the identifier of the estimate to delete. Take it from the list step that found the stale quotes in the first place.

This one has a second job: it reads the estimate and can hand back the document itself as a file.

• Estimate ID: which estimate to retrieve.
• Download: on, the estimate comes back as a PDF file.
• Put Output File in Field: the name of the binary field the file is placed in.
• File Name: how the file is named, data.pdf by default.

Open quotes rarely sit in one place. This lists them from the books so a workflow can sort, count or chase them.

• Return All: switch it on when the point is a complete picture of the pipeline.
• Limit: how many estimates come back otherwise.
• Query: the selection condition, for example everything updated after a chosen date.

QuickBooks does the emailing itself. The node hands over an estimate and an address, and the document goes out from the accounting side.

• Estimate ID: the estimate to send.
• Email: the recipient address, in the form name@email.com, often taken from the customer record fetched a step earlier.

Revised quotes stay on the same record instead of piling up as duplicates. Name the estimate, then list what changes.

• Estimate ID: the quote being revised.
• Update Fields: ten values, including Billing Email, Customer Memo, Document Number, Transaction Date, Email Status and Print Status.

Posting a new invoice into QuickBooks starts here, and the node returns the created record so the next step can reuse its ID.

• For Customer Name or ID: the customer the invoice is billed to, picked from the dropdown or set with an expression, which is how n8n reads a value from the previous item, for example {{ $json.customerId }}.
• Line: the billed lines, where Amount, Description, Quantity and Item Name or ID spell out what is charged; Detail Type offers a single value, SalesItemLineDetail.
• Due Date and Customer Memo: the payment deadline and the message the customer sees on the document.

Deletion is final on the QuickBooks side, so this node belongs behind a condition or a manual approval rather than in the middle of a fast loop.

• Invoice ID: the identifier of the invoice to delete, a required string. The node wants the ID, not the document number shown on the invoice, so it usually comes from a previous Get Many step through an expression such as {{ $json.Id }}.

One invoice, read by its identifier, with an option that few people notice: the same operation also hands you the PDF.

• Invoice ID: the identifier of the invoice to retrieve.
• Download: switched on, the invoice comes back as a PDF file instead of plain fields.
• Put Output File in Field: the name of the binary field that carries the file to the next node.
• File Name: the name the downloaded file takes, data.pdf by default.

Lists of invoices come out of this operation, which is the one most reporting workflows start with.

• Return All: enabled, n8n walks every page of the QuickBooks API and returns all invoices; disabled, Limit caps how many come back.
• Limit: the maximum number of invoices returned when Return All stays off, handy while testing.
• Query: a filter condition in the QuickBooks query syntax, for instance WHERE Metadata.LastUpdatedTime > '2021-01-01', so a scheduled run only picks up what changed.

Delivery is handled by QuickBooks itself: the node names the invoice and the address, and the document goes out.

• Invoice ID: the identifier of the invoice to send.
• Email: the recipient address, in the name@email.com form. It overrides nothing on your side, so pull it from the record you already hold, for example the billing contact stored with the deal.

Corrections go through Update, which touches only the fields you list and leaves the rest of the invoice untouched.

• Invoice ID: the identifier of the invoice to update, required.
• Update Fields: the collection of values to change, ten fields in total. Due Date pushes a deadline, Billing Email fixes a wrong address, Document Number aligns the reference with another system.
• Email Status and Print Status: flags such as NeedToSend or NeedToPrint that mark what still has to happen to the document.

Void sits beside Delete in the Invoice resource, and the node asks for nothing more than the identifier.

• Invoice ID: the identifier of the invoice to void. Pick it from the item flowing in rather than hardcoding it, since a voided document is not something you want to aim at the wrong row.

Products and services live in the Item resource, and this operation reads one of them by identifier. The node only reads items: creating or editing a product goes through the HTTP Request node instead.

• Item ID: the identifier of the item to retrieve, required.

The whole catalog of products and services comes back here, which is what you want when a workflow has to map an external SKU onto a QuickBooks item.

• Return All: on, every item is fetched page by page; off, Limit decides how many arrive.
• Limit: the ceiling on the number of items returned.
• Query: a condition in QuickBooks query syntax for selecting items, useful to narrow a long catalog.

Money received gets recorded with this operation, which books a payment against a customer.

• For Customer Name or ID: the customer the payment belongs to, chosen in the list or resolved with an expression when it comes from an earlier node.
• Total Amount: the amount of the transaction.
• Transaction Date: the date the payment happened, worth setting explicitly when the workflow runs a day after the fact.

A payment booked twice is the classic reason to reach for this operation, and it needs one value.

• Payment ID: the identifier of the payment to delete, required. Get Many is the usual way to find it, filtered on the transaction you suspect, because the node matches on the identifier and never on the amount.

Reading a single payment gives the workflow the detail behind an amount, and the operation can hand over a PDF as well.

• Payment ID: the identifier of the payment to retrieve.
• Download: turned on, the node downloads the document as a PDF file.
• Put Output File in Field: the binary field that carries that file onward.
• File Name: the name given to the downloaded file, such as data.pdf.

Reconciliation work starts with a list, and this is the operation that produces it.

• Return All: enabled, the node keeps paging until every payment is in; disabled, it stops at Limit.
• Limit: the maximum number of payments returned.
• Query: the selection condition, for example a filter on Metadata.LastUpdatedTime so a scheduled run only reads the payments booked since the last pass.

Customers who want a written trace of what they paid are the audience for this one: QuickBooks emails the payment record to the address you pass.

• Payment ID: the identifier of the payment to send.
• Email: the recipient address, written as name@email.com.

The Payment resource keeps its update surface narrow: one identifier, one collection, and a single field inside it.

• Payment ID: the identifier of the payment to update, required.
• Update Fields: the required collection holding the change; leave it empty and there is nothing to apply.
• Transaction Date: the date the transaction occurred, the value this operation lets you rewrite.

Alongside Delete, the node exposes Void for payments, and it takes a single value to run.

• Payment ID: the identifier of the payment to void. Feed it from the item coming in, typically the record a check-failure notification pointed at.

Purchases are read-only in this node, so the two operations available are about looking, not writing. This one returns a single purchase.

• Purchase ID: the identifier of the purchase to retrieve, required.

Spend reviews need the whole set rather than one row, which is what this operation returns.

• Return All: on, every purchase is retrieved across pages; off, the run stops at Limit.
• Limit: how many purchases at most come back.
• Query: the condition for selecting purchases, in the query syntax QuickBooks documents, so a monthly job can target a single period.

The Transaction resource carries one operation, and it is the analytical one: a transaction report built from the filters you set, without required fields to fill in first.

• Simplify: returns a trimmed version of the response instead of the raw report structure, easier to map into a sheet.
• Filters: the shaping controls, 27 of them. Date Range (Predefined) takes values such as Last Month, Transaction Type narrows to Invoice or Bill, Group By aggregates by Customer or Month, Columns picks the columns returned.

New suppliers enter the books through this operation, which needs one value and accepts eleven more.

• Display Name: the name the vendor is created under, required and the only mandatory field.
• Company Name, Primary Email Address, Primary Phone: the contact details worth filling from the start, because a vendor without an email blocks every later notification.
• Vendor 1099: marks the vendor as an independent contractor, the one given a 1099-MISC form at year end.

Fetching one supplier record is the check that saves a workflow from writing to the wrong account later on.

• Vendor ID: the identifier of the vendor to retrieve, required. Company names repeat and change; the identifier does not, which is why the node asks for it.

Supplier lists come out here, whether for an audit, a data migration or a lookup table.

• Return All: enabled, n8n pages through the API until the full vendor list is in hand; disabled, it returns up to Limit.
• Limit: the maximum number of vendors returned.
• Query: the selection condition for vendors, which is how you keep a large book down to the accounts that matter.

Bank references, addresses and contact people move around; this operation writes the change back without touching anything else.

• Vendor ID: the identifier of the vendor to update, required.
• Update Fields: the required collection of changes, eleven fields wide, covering Primary Email Address, Billing Address, Account Number and Print-On-Check Name.
• Active: whether the record stays enabled for use in QuickBooks, the clean way to retire a supplier you no longer work with.