Build: Invoice settlement

In one line. Invoices land in a Processing collection, an Invoice Extractor agent pulls the fields, the Four-Eyes lifecycle auto-approves clean small ones and routes the rest to two human reviewers via the Inbox, and approved invoices export to your finance system. You’ll build. A complete, audited invoice pipeline — collection, fields, ingestion, extractor agent, an auto-approve gate, export on approval, and a scoreboard page — in about 45 minutes, entirely by configuration. You’ll use. Collections & schema · Taxonomy, lifecycle, tags & events · Ingestion & connectors · Your first agent · Document detail · Dashboards & inbox · Pages & cards

This is the canonical “decide on each document” shape — structured extraction + human-in-the-loop + export over a Processing collection. Learn it here and the triage, contract and compliance builds are variations on it. Before you start you need a project you can build in, at least one language model registered (LLMs & services), the agent-and-collection model from Core concepts, and a handful of sample invoice PDFs.

 INGESTION                COLLECTION (Processing)                    EXPORT
 Drive / Upload  ──►  Vendor Invoices                        ──►  Finance system
                       fields: vendor_name, invoice_number,         (Blob / Drive /
                               invoice_date, total_amount,          webhook)
                               due_date, line_items (table)
                       worker: Invoice Extractor fills the fields
                       lifecycle: Four-Eyes
                         clean and under $500 ──► auto-approve
                         everything else ──► L1 Review ► L2 Approval (Inbox)
                       experience page: Processed / Pending / Flagged

Steps

Stage 1 — Create the “Vendor Invoices” Processing collection

Goal: a typed home for invoices, with review stages.

1. Go to Studio > Data > Collections and click + Collection at the bottom of the list.
2. Purpose: Processing (the default). This choice is immutable after create — pick Processing deliberately.
3. Collection Name: Vendor Invoices. Description: Incoming supplier invoices for approval.
4. Leave every other accordion at its default and click Save.

If you don’t see a Processing / Knowledge choice, new collections are Processing anyway — which is what this build wants. The choice can be switched off for a workspace; if you need it, ask your administrator.

Checkpoint. Vendor Invoices appears in the collection list. Select it and the right pane shows its tab strip: General · Taxonomy · Lifecycle · Tags · Events · Ingestion · Agents. The Lifecycle tab is already seeded with the 8-stage Four-Eyes flow — you tune it in Stage 5.

Full field-by-field reference: Collections & schema.

Stage 2 — Design the fields to extract

Goal: tell the platform exactly what to pull out of every invoice. Fields drive extraction — no Label, no extracted value.

1. With Vendor Invoices selected, open the Taxonomy tab and click Taxonomy at the bottom of the list to create the Learner that owns the fields.

2. Enter the Learner: Taxonomy Name Invoice Header, Description Top-level invoice fields, Type DocumentClassification (whole-document field extraction), Entity Vendor Invoices (pre-filled). Click Submit.

3. Select Invoice Header, then + Label. A field’s type comes from a validation rule (under View Config) plus Record Config — there is no single “type” dropdown (Collections & schema). Add these, using Add between each:

   Label Name	Description	How to make its type
   vendor_name	The supplier's name	Plain text — no advanced settings
   invoice_number	The supplier's invoice number	Plain text
   invoice_date	Date the invoice was issued	View Config → add a date validation rule
   total_amount	Grand total including tax	View Config → numeric validation rule; optionally tick Enable Total Field for a column total
   due_date	Date payment is due	View Config → a date validation rule

4. Now the line-items table. Click + Label again: Label Name line_items, Description One row per billed line. Open Record Config and turn on Is Record. Add child Labels as its columns: description (text), quantity (numeric), unit_price (numeric). Click Add and exit.

Checkpoint. The Labels tree under Invoice Header shows all six fields, with line_items as a table carrying 3 child fields. Exhaustive validation options: Schema field reference.

Stage 3 — Wire ingestion (get invoices into the collection)

Goal: a repeatable way for invoice PDFs to land in Vendor Invoices. Go to Studio > Data > Ingestion (Ingestion & connectors).

One note on old links. An older single-source setup wizard still opens from bookmarks, but it is no longer in the menu. Build new sources on Studio > Data > Ingestion.

The fast path, for testing right now: click Upload, drag in a few invoice PDFs, set Target collection = Vendor Invoices, Submit. Use this to smoke-test your fields before automating — you’ll do exactly this in Stage 9.

The recurring path, for production — a connector must exist before a job can use it:

1. + Connector → pick Botminds Drive (this project’s internal drive — no credentials). Give it a name → Test connection → Save connector.
2. + Job → Step 1: select that Drive connector. Step 2: Job name Invoices intake; Browse… to the invoices folder; Extensions pdf; tick Recursive; Target collection Vendor Invoices. Step 3: Recurring → every 6 Hours (check the Next 5 runs preview) → Create job.

Checkpoint. On the Jobs tab you see Invoices intake … active. Click Run now, then the Runs tab — the funnel counters (Enum → Fetch → New → … → Disp) fill, and a click on the run opens Run detail with a per-file log.

Stage 4 — Build and assign the “Invoice Extractor” agent

Goal: an AI worker that fills the six fields on every invoice. Go to Studio > Agents > Agent Toolkit > Agents → + Agent ▸ Agent at the bottom of the list. This opens the tabbed builder beside a live playground (Your first agent).

1. Persona tab. Name Invoice Extractor; Description Extracts header fields and line items from vendor invoices. Click the co-pilot on Instructions, seed it with “Extract the key fields and line items from a vendor invoice,” then refine to roughly:

   You are an invoice-processing assistant. For each invoice, extract the
   vendor name, invoice number, invoice date, due date, total amount, and
   every line item (description, quantity, unit price). Return only values
   the document supports; never invent one.

2. Model tab. Pick your project’s language model (LLMs & services). Set Agent Mode = Thinking while you tune, so you can watch its reasoning; leave Advanced sampling at defaults.

3. Output tab. Turn on Structured output. Pick the Taxonomy/Learner Invoice Header, set Process unit = Page, confirm the Labels (vendor_name, invoice_number, invoice_date, total_amount, due_date, line_items) each carry a short Description, and turn on Confidence Score and References. Per-field confidence is what routes a document to human review later.

4. Click Save Agent — there is no autosave.

5. Test it before wiring it up. In the right Playground pane: Input Type = Document, pick a sample invoice, press Enter. Watch the fields stream in with confidence and page references. Flip Agent Mode = Fast and re-run — same fields, quicker; that is your production setting.

6. Assign it as the collection’s Worker. Go back to Studio > Data > Collections, select Vendor Invoices → Agents tab → Assign Invoice Extractor as the intake/processing agent.

Checkpoint. The Agents tab shows Invoice Extractor assigned, with a link back to the agent editor. From now on every document that lands in Vendor Invoices is run by it automatically. The Worker you set here runs on each document as it arrives; a Reader is the other relationship — an agent that answers questions over data, attached on the agent’s own Knowledge tab (Your first agent).

Stage 5 — Configure the lifecycle (auto-approve small, route the rest)

Goal: keep Four-Eyes for real money, but stop sending tiny clean invoices to two humans. Open Studio > Data > Collections, select Vendor Invoices → Lifecycle tab. The 8-stage Four-Eyes flow is already there (Intake → AI Processing → AI Recommendation → L1 Review → L2 Approval → Needs Info → Approved/Declined). You add one auto-approve rule and confirm the review routing — full detail in Taxonomy, lifecycle, tags & events.

1. Auto-approve under $500. Below the stage graph, open the Auto-Decide policy card and set:
   • Enabled = true
   • Applies To = approve (auto-approve only; always keep human eyes on declines)
   • Max Amount = 500, and set the Amount Field to total_amount
   • Leave Min Confidence = 0.92 and Require Zero Flags = true (the defaults).
   • Save. The preview should read roughly “Auto-approve when AI confidence ≥ 0.92 AND zero flags AND amount ≤ $500.”
2. Confirm the review stages send to the Inbox. Click the L1 Review stage to open the State editor and confirm Send to Inbox (human review) is on; do the same for L2 Approval. These are what put items in a reviewer’s queue. In the seeded flow they’re already on — you’re verifying, not adding.

Checkpoint. The Auto-Decide card shows your $500 preview. Clean invoices under $500 now skip both reviewers; everything at $500 or above, low-confidence, or flagged still routes to L1 Review → L2 Approval and lands in the Inbox. Do not use Reset to default on a lifecycle with live documents — it rebuilds the standard flow and asks you to confirm by typing the collection’s identifier.

Stage 6 — Walk the review path (how a human corrects and approves)

Goal: know exactly what your reviewers do, so you can design toward it. A document that doesn’t auto-approve enters L1 Review and the platform creates an Inbox item that wraps it. The reviewer’s path:

1. Consumer app ▸ Inbox. Under Needs Review / Needs Approval, each card shows a headline, a provenance line (wraps ▸ Vendor Invoices · doc-… · L1 Review), age, and the amount. The Inbox doesn’t act — it is read + snooze + dismiss only (Dashboards & inbox).
2. Click Open — you land on the Document Detail page, a split view: the invoice on one side, the extracted fields on the other (Document detail).
3. In the Summary pane, read the flagged (low-confidence) fields first. Click a value — say Total : $1,240.00 — and the viewer scrolls to and highlights the source segment it was read from. That is how you catch a mis-read, such as a subtotal grabbed instead of the grand total.
4. Correct a wrong value by editing it in place; your edit saves back to the label and becomes a teaching signal for the trainable model (AI Builder). Run Rescore if dependent values need recomputing.
5. Advance the document from the workflow action pane: approve sends it to L2 Approval (the second eye), who finalises it to Approved. Every move is written to the audit trail — that trail is the decision. Read it at Studio > Governance > Oversight > Audit & Usage.

Checkpoint. When the reviewer advances the document past its human stage, the Inbox item resolves itself — it leaves the queue automatically. Editing needs the Reviewer role, or a persona that grants it; a Viewer gets a read-only summary.

Stage 7 — Export approved invoices

Goal: push approved invoices, with their extracted data, out to your finance system. Go to Studio > Data > Export → + Export (Ingestion & connectors).

1. Pick the Export Type first — the rest of the form follows from it. Name: Finance export. Choose a split/bookmark type if you want structured output, or a plain type to ship the data as-is.
2. Destination: under External Sources, either Azure Blob (Storage Name / Key / Container) or Botminds Drive (drive URL). Useful common toggles: Export input document (ship the original PDF alongside the data) and Add date-wise folders. Save (disabled while the form is invalid).
3. Fire it on approval (recommended). So export happens the moment an invoice is approved, add an Event instead of exporting by hand: Vendor Invoices ▸ Events tab → + Event → trigger stage change, Workflow Four-Eyes, Stage Approved, + Add Action → Webhook to your finance endpoint (Taxonomy, lifecycle, tags & events). Alternatively, an Export-type automation on the Approved stage runs the export template on entry.

Checkpoint. Your export appears in the Export list with its Type, Taxonomy chips, and Storage details. Drive one invoice to Approved and confirm the file or POST lands.

Stage 8 — Add a scoreboard: processed / pending / flagged

Goal: a bird’s-eye score of the pile for your finance lead. Go to Studio > Experience > Designer > Pages, create a page, choose a layout, and drop in cards from the card library at Studio > Experience > Designer > Cards (Pages & cards). Placing a card is: drop it in → configure it in the inspector → point it at your data → save.

1. Processed — a count card filtered to stage Approved.
2. Pending — a count card filtered to stages L1 Review + L2 Approval (what’s waiting on a human).
3. Flagged — a count card over documents carrying a review flag or a Wrong Vendor-type Tag.

Checkpoint. Preview the page to see exactly what your end users get. Page design can be switched off for a workspace — if you don’t see the Pages entry, ask your administrator.

Stage 9 — Test it end to end

About ten minutes:

1. Upload a sample. Studio > Data > Ingestion → Upload → drag in one invoice PDF — use a small one, under $500, and a larger one to see both paths → Target collection = Vendor Invoices → Submit. The result panel reports “N of M registered.”
2. Watch it process. Open the consumer document list for Vendor Invoices. The new row shows a Processing… chip that climbs to 100% as the Invoice Extractor fills the fields — live, no refresh (Document detail). If a row sits at 0% for a long time, tell your administrator (Ingestion & connectors).
3. See routing in action. The under-$500, clean invoice should auto-approve — its audit entry records an automatic accept rather than a person — and skip the humans. The larger one should land in the Inbox under Needs Review.
4. Review in the Inbox and Document Detail. Open the Inbox item → Open → on the Document Detail, click a field to verify it against its highlighted source, correct one value, then approve from the action pane. It moves to L2 Approval; approve again → Approved, and the Inbox item disappears.
5. See it exported. Confirm the Approved invoice triggered your Finance export — a file in Blob/Drive, or a POST to your webhook.
6. Read the scoreboard. On your page, Processed ticks up and Pending reflects anything still in review.

If all six happened, you have a working, audited invoice pipeline — built entirely by configuration.

Make it production-worthy

Four upgrades, in rough order of effort:

1. More fields. Add purchase_order_number and tax_amount Labels to the Invoice Header Learner (Stage 2), then add matching Labels with Descriptions on the agent’s Output tab (Stage 4) and Rescore existing documents. The Learner and the agent must agree, or the field stays empty.
2. A “Wrong Vendor” tag and an Overdue view. On the Tags tab add Duplicate, Missing PO, Wrong Vendor for reviewers to apply (Taxonomy, lifecycle, tags & events). Then define an Overdue Invoices View at Studio > Data > Views (columns: Vendor, Total, Due Date, Status; filter on due date / status), Type = Project, and set which personas can use it. Views sits under Data, not under Experience > Search — that’s where most people look first. Your reviewers now get a one-click “what’s overdue” list.
3. A webhook with an SLA alert. Extend the Stage-7 Event — under Show Advanced Settings set Check SLA Breach and SLA Time so you’re alerted when an invoice sits in review too long (Taxonomy, lifecycle, tags & events).
4. A stricter approval threshold. Lower the Auto-Decide Max Amount to 100 (or raise Min Confidence to 0.97) so more invoices get human eyes — or set Applies To = both only once you trust the agent on declines too. Tune the gate to your risk appetite (Stage 5).

Where to go next

• Build: Support intake triage — the same building blocks assembled to sort each document instead of settle it.
• Taxonomy, lifecycle, tags & events — the Auto-Decide policy, Conditional automations, and Events in full.
• Build: Policy knowledge assistant — the other big pattern: answering questions over a corpus.