How do I attach source documents to Rillet bills?

Rillet has a dedicated endpoint for attaching a file to an already-created bill — a separate call from creating the bill itself. A workflow uploads the file as multipart form data to the bill's own endpoint; a successful upload returns no content, and the attachment only exists once this second call actually happens.

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.

Endpoint	POST /bills/{bill_id}
Content type	multipart/form-data — the file is sent as binary data
Object scope	Bills only, per the endpoint's path structure — not invoices, contracts, or other object types
Success response	204 No Content
Relationship to bill creation	A separate call — creating a bill does not itself attach a document

Something none of the other ERPs in this matrix expose

NetSuite, Sage Intacct, QuickBooks, and Xero's bill actions in this matrix all handle the bill record itself — vendor, amount, line items, due date — without a first-class action for attaching the underlying source document (the vendor's actual invoice PDF or receipt). Rillet's integration has one: a dedicated upload endpoint scoped specifically to bills, separate from creating the bill record.

How the upload call works

The endpoint is POST /bills/{bill_id}, and it expects the file as multipart form data rather than a JSON body — the file itself is the payload, sent as binary data. A successful call returns 204 No Content: there's no response body to parse, just confirmation the attachment landed. The endpoint's path makes the scope explicit — it only attaches to bills, not to invoices, contracts, or any other Rillet object type.

Why the two-call structure matters for workflow design

Creating a bill and attaching its source document are two separate API calls, not one atomic operation. A workflow that creates a bill and stops — without a second call to the upload endpoint — produces a bill with no backup attached, even though the bill itself is entirely valid and payable. Designing this correctly means treating the upload call as a required step in the same workflow run, not an optional follow-up, and building in a check for whether it actually succeeded rather than assuming it did because the bill creation succeeded.

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

Checklist

Bill creation + document attachment as one workflow run

Create the bill record and capture its bill_id from the response
Immediately call POST /bills/{bill_id} with the source document as multipart form data
Confirm the upload call returned 204 — don't assume success just because bill creation succeeded
If the upload call fails, surface it as a distinct error from a bill-creation failure — the bill still exists either way

Frequently Asked Questions

No — bill creation and document upload are two separate endpoint calls. There's no combined single-call option documented for creating a bill with an attachment already included.

Rillet's published specification for this endpoint doesn't state explicit file-type or size restrictions — confirm current limits directly with Rillet before relying on a specific file size in production.

Not through this endpoint — its path (/bills/{bill_id}) scopes it specifically to bills. A different object type would need a different, separately documented endpoint if one exists.

Sources

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…

Diagnostic

What breaks when a Rillet bill is missing its source document?

Creating a Rillet bill and attaching its source document are separate API calls, so a workflow that fails between the two can create a fully valid, payable bill with no backup attached. The bill won't look broken — it passes approval and payment normally, and the gap only surfaces if someone checks for the attachment at audit or close.