How do I look up or update an AP bill in Xero?

Use getInvoice, updateInvoice, or listInvoices with the bill's InvoiceID — Xero has no separate Bill resource. A bill is an Invoice with Type=ACCPAY, and Loopfour's Xero integration exposes full get/update/list for Invoices generically. createBill is a convenience wrapper for creation only; reading and updating a bill happens through the Invoice actions, not a Bill-named one.

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 Xero's data model actually is	One Invoices resource, distinguished by Type (ACCREC = sales, ACCPAY = bills)
Loopfour actions that cover bills	getInvoice, updateInvoice, listInvoices, deleteInvoice, voidInvoice — all operate on Invoices generically
What createBill actually is	A convenience wrapper around createInvoice with Type=ACCPAY set — not a separate object type
Common mistake	Looking for a getBill/updateBill/listBill action by name — none exists, because none is needed

Why there's no dedicated "Bill" action to look for

Xero's Accounting API models sales invoices and vendor bills as the same resource — Invoices — distinguished only by a Type field (ACCREC for sales, ACCPAY for bills). Xero's own OpenAPI specification documents one set of endpoints for that resource: GET /Invoices, GET /Invoices/{InvoiceID}, POST/PUT for creating and updating. There's no separate Bills endpoint, because Xero doesn't have a separate Bills resource.

Loopfour's Xero integration follows that same shape: getInvoice, updateInvoice, listInvoices, deleteInvoice, and voidInvoice all operate on the generic Invoices resource, and all of them work on a bill exactly the way they work on a sales invoice — pass the bill's InvoiceID (or filter listInvoices to Type=ACCPAY) and they return or modify the bill. createBill exists as a separate, convenience-named action, but it's implemented as a thin wrapper around createInvoice with Type fixed to ACCPAY. It's the only Bill-specific name in the whole integration, which is exactly what makes it easy to assume the read/update/list side needs a Bill-named counterpart that was never built. It doesn't — the general Invoice actions already cover it.

What this looks like in practice

A workflow that creates a bill with createBill gets back an InvoiceID in the response. To check its status later (draft, submitted, authorised, paid), call getInvoice with that same InvoiceID — not a separate lookup path. To correct a wrong amount or due date, call updateInvoice with that InvoiceID. To audit a batch of bills created over a period, call listInvoices filtered to Type=ACCPAY and a date range, rather than checking Xero's UI by hand.

One real gap: there's no separate vendor object

Xero has no dedicated vendor entity — a bill's supplier is a Contact, the same object type used for customers. That's a genuine structural difference from ERPs with a separate vendor-bill object, though it doesn't limit read/update/list the way this page originally assumed the Invoice actions did. It does mean vendor-side fields on a bill are only as rich as whatever a Contact record carries.

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

Field mapping

Xero's Accounting API vs. Loopfour's Xero bill integration

Operation	Xero's Accounting API	Loopfour's Xero integration
Create a bill	POST /Invoices (Type=ACCPAY)	createBill (wraps createInvoice)
Retrieve one bill	GET /Invoices/{InvoiceID}	getInvoice (generic — no getBill exists, none needed)
List bills	GET /Invoices	listInvoices, filtered to Type=ACCPAY
Update a bill	POST/PUT /Invoices/{InvoiceID}	updateInvoice (generic)

Frequently Asked Questions

No — it's only the creation path. Reading, updating, listing, voiding, and deleting a bill all go through the generic Invoice actions (getInvoice, updateInvoice, listInvoices, voidInvoice, deleteInvoice), using the bill's InvoiceID.

Pass a where clause filtering on Type=="ACCPAY" — listInvoices accepts a raw where parameter that maps directly to Xero's own query syntax.

No — Xero's own OpenAPI specification documents full GET, list, and update support for the Invoices resource, which covers bills. There's no gap on either Xero's or Loopfour's side; the only trap is expecting a Bill-named action that was never needed.

Yes, in spirit — Xero has one Contact object for both customers and vendors, not separate entities. That's a related but distinct fact from the Invoices/Bills unification this page covers.

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.

Topic

Integrations

Every finance automation vendor publishes an integrations page: a grid of logos, a claim of "seamless" connectivity, and not much else. That page answers a marketing question — does this vendor touch…