Skip to main content
This guide walks through the end-to-end flow of processing a bill via the Dolfin API. You’ll get a bill into Dolfin — either by forwarding it to a dedicated email address or by uploading it through the API — optionally correct any fields the extraction got wrong, submit the bill for review, and let your approval policies decide whether it auto-approves or routes to an approver.

Prerequisites

  • A Dolfin API key
  • An organisation already provisioned (see Client Integration)
  • A valid session token or API key for authentication
  • A bill PDF or image file to upload (or an email inbox to forward from)
All requests below require the x-dolfin-api-key and x-dolfin-organisation-id headers. See Authentication for details.

Overview

1

Get the bill into Dolfin

Either forward it to your organisation’s inbound email address, or upload it via POST /v1/bills. Both create a bill and read the document asynchronously.
2

Patch extracted fields (optional)

Fix any fields the extraction got wrong while the bill is in PendingReview.
3

Submit for review

Submit the bill. Your approval policies decide the next state — auto-approve, route for approval, or void.
4

Approve or reject

An approver takes the final call on any bill that lands in NeedsApproval.

Bill lifecycle

A bill moves through these states:
The branch after submit for review is decided by your approval policies. With no policies configured, every bill with a resolved supplier goes to NeedsApproval (the safe default).

Step 1: Get a Bill into Dolfin

There are two ways to bring a bill in. Both end up in the same place: a bill in Extracting that moves to PendingReview once the document has been read.

Option A — Forward it by email

Every organisation has a dedicated inbound email address. Forward supplier bills to it (or ask suppliers to send them there directly) and Dolfin ingests the attachments, creating one bill per document — no code required. Fetch the address with GET /v1/bills/inbound-email-address:
Response (200 OK):
Surface this address in your UI with a copy button so users can save it as a contact. Any email sent to it with a PDF or image attachment becomes a bill.
Sender allowlisting. To stop a leaked address being abused, Dolfin only auto-ingests mail from allowed senders — your organisation’s own users are trusted automatically, and you can add colleagues or suppliers explicitly. Mail from an unknown sender is quarantined for a human to approve rather than silently accepted or bounced, so a genuine bill from a new address is never lost.

Option B — Upload it via the API

Upload the bill document as multipart/form-data. The document is read asynchronously, so the response returns immediately with the new bill’s id and initial state.
Response (202 Accepted):
Save the bill id — you’ll use it in every subsequent call. The bill starts in Extracting and automatically moves to PendingReview once the document has been read. Subscribe to the bill.pending_review webhook to be told when, or poll GET /v1/bills/{id}.

Wait for extraction to finish

Whether the bill arrived by email or upload, its fields aren’t populated until the document has been read. There are two ways to find out when that’s done. Recommended — subscribe to a webhook. Dolfin posts bill.pending_review to your endpoint the moment extraction completes, with the full bill in the payload, so there’s nothing to poll and no follow-up call to make. Subscribe to bill.ocr_failed too, to catch documents that couldn’t be read. See the webhooks guide to set one up. Otherwise — poll the bill. If you don’t have an endpoint to receive webhooks, fetch the bill until it leaves Extracting. Forwarded bills don’t return an id to you directly — list recent bills with GET /v1/bills to find them.
Once the state is PendingReview, the extracted fields are populated on the bill:
If the state becomes ExtractionFailed, the document couldn’t be read. Call POST /v1/bills/{id}/retry-ocr to try again.
Extraction methods. Dolfin can read bill documents with either OCR or LLM vision extraction. Which one your account uses is configured per client — contact us to switch. The states, fields, and events are identical either way.

Step 2: Patch Extracted Fields (Optional)

Extraction isn’t perfect. If any fields came out wrong — the supplier name, invoice number, amounts, line items, bank details — patch them while the bill is in PendingReview.
Only the fields you include are updated — everything else stays as extracted. You can only patch bills in PendingReview; attempts against any other state return 409 Conflict.
To link the bill to an existing supplier record, set supplierId to the supplier’s UUID. Otherwise the free-text supplierName, supplierEmail, etc. are kept as-is and used for supplier resolution when you submit for review (see Step 3).

Step 3: Submit for Review

Once the extracted data is correct, submit the bill. This runs supplier resolution and then evaluates your approval policies to decide the bill’s next state.

Supplier resolution

When you submit a bill for review, Dolfin resolves the bill’s supplier in this order:
  1. If you set supplierId explicitly (via patch), that supplier is used.
  2. Otherwise, Dolfin looks for an existing supplier on the organisation whose tax ID or email matches the extracted value and links to it.
  3. If no match is found, a new supplier is created from the extracted data. This requires at minimum supplierName and supplierEmail — fill these via PATCH /v1/bills/{id} in Step 2 if extraction didn’t capture them. Any other extracted details (phone, address, website, tax ID, bank details) are copied onto the new supplier too.
If the bill has no linked supplier and not enough data to create one, submit-review returns 400 Bad Request.

How approval policies steer the bill

At submit time, Dolfin evaluates your organisation’s ordered list of approval policies against the resolved bill (its amount, currency, supplier, and supplier standing). The highest-priority matching policy decides the outcome: If no policy matches, the bill goes to NeedsApproval — the safe default. The response reflects the state the winning policy produced:
See the Approval Policies guide to configure auto-approve thresholds, per-supplier rules, and named approvers. A bill that auto-approves lands in Approved and skips Step 4.
Using purchase orders or delivery notes? When a bill matches against a PO or delivery note, Dolfin creates a match group, and a bill cannot leave review for approval while its match group is unresolved — any price or quantity variance must be resolved first. See the Three-way Matching guide.

Step 4: Approve or Reject

With the bill in NeedsApproval, an approver takes the final call.

Approve

Response:
An approved bill is ready for payment scheduling via POST /v1/bills/{id}/schedule-payment.

Reject

If something’s off, reject the bill with an optional reason.
Response:
A rejected bill can be re-opened for editing with POST /v1/bills/{id}/reopen, which returns it to PendingReview.

Summary

Next Steps

Approval Policies

Auto-approve trusted bills and route the rest to the right approver.

Three-way Matching

Match bills against purchase orders and delivery notes before approval.

Supplier Credit Notes

Record credit a supplier owes you and net it against bills.

API Reference

Explore the full Bills API, including payment scheduling and file URLs.