AP · Invoice intake
Multi-workflowAccounts payableFrom the AP inbox to an approved bill, with every match on record
Invoices arrive as PDFs in a shared inbox, and someone types them into the ledger. Here is a three-workflow setup that reads them, checks them against the purchase order and receipt, and only creates the bill once a person approves it.
Valnora & Elric team6 min read
- WorkflowsThe visual builder: blocks, models and integrations wired into agent logic.
- TablesA database, built in, for cases, queues and decisions.
- RulesPlain-language checks that pass, fail or flag a record.
- LogsEvery run traced block by block.
- FilesOne store for documents your team and agents share.
- DashboardsCharts, tables and KPI tiles over governed metrics.
A mid-sized distributor gets a few hundred supplier invoices a month. Most arrive as PDFs in ap@ and a clerk keys each one into the ledger, opens the purchase order in another tab and checks the warehouse receipt in a third. The matching is where the time goes, and where the errors hide: a short delivery billed in full, a duplicate sent from two email addresses, a supplier whose bank details changed last week.
This post lays out three workflows in Agent Serve that take over the reading and matching. People keep the decisions: an approver says yes before any bill is created, and every exception lands with a named owner.
The shape of the solution
Three workflows from inbox to bill
Workflow 1 · Intake
- 01AP inboxA Gmail or Outlook trigger starts a run for each new email to the AP address.
- 02Parse the invoiceTextract, Reducto or Mistral Parse reads the PDF; an agent block maps it to supplier, PO, lines and totals.
- 03Invoices tableOne row per invoice, with the PDF saved to Files and a link on the row.
Workflow 2 · Match
- 04PO and receiptPurchase orders and goods receipts read from QuickBooks or NetSuite, or a receipts table.
- 05Tolerance rulesPrice, quantity and total tolerances, duplicate checks and bank detail changes.
- 06Exceptions queueAnything that fails a rule gets a reason code and an owner.
Workflow 3 · Approve and post
- 07Human in the loopThe budget owner sees the invoice, the match result and any exception note.
- 08Bill createdThe bill is created in QuickBooks or NetSuite with the PDF attached and the row updated.
Each workflow has one job, and all three share an invoices table in Tables. The table is the source of truth for where every invoice stands: received, matched, exception, waiting for approval, posted.
Workflow 1: read every invoice that lands
A Gmail or Outlook trigger starts a run for each new email to the AP address. The workflow:
- Saves each PDF attachment to a supplier folder in Files.
- Sends it to a document parsing block. Textract, Reducto and Mistral Parse all ship as blocks; pick the one that reads your suppliers' layouts best.
- Passes the parsed text to an agent block with a fixed output format: supplier name and tax ID, invoice number and date, PO number, currency, line items with quantity and unit price, tax and total.
- Writes one row to the invoices table with status Received and a link to the PDF.
Emails without an attachment, or with something that is not an invoice (a statement, a remittance advice, a marketing newsletter), are written as Not an invoice with the reason, so nothing disappears without a trace.
Workflow 2: the three-way match
A table trigger runs when a row arrives with status Received. The workflow looks up the purchase order in QuickBooks or NetSuite by the PO number on the invoice, and the goods receipt from the ledger or a receipts table the warehouse keeps.
The checks live in Rules, written in plain language so the controller can read and change them:
- Price. Each unit price within 1% of the PO price, as an example tolerance.
- Quantity. Billed quantity no more than 2% above the quantity received.
- Total. Invoice total within a small fixed amount of PO value times quantity received, to allow for rounding and freight.
- Duplicate. No other invoice from the same supplier with the same number, or the same amount within 30 days.
- Bank details. Payment details on the invoice match the supplier record. A change always fails, whatever the amount.
Invoices that pass every rule move to Waiting for approval. Anything that fails goes to an exceptions queue with a reason code, the evidence and a suggested next step.
What the solution produces
Exception row in the queue (illustrative)
Record- Invoice
- INV-88214 · Northfield Packaging · 4,820.00 USD
- Purchase order
- PO-3107 · 2,000 shipping cartons at 2.30 USD
- Goods receipt
- 1,800 cartons received on 2 October, per the warehouse receipt
- Failed rule
- Quantity: invoice bills 2,000 units, receipt shows 1,800. Outside the 2% quantity tolerance.
- Other checks
- Unit price matches the PO. No duplicate found. Bank details unchanged.
- Suggested next step
- Ask the supplier for a credit note for 200 units, or confirm a second delivery with the warehouse.
- Owner
- AP specialist for packaging suppliers
The bank details rule deserves its own line. Invoice fraud often arrives as a genuine-looking invoice with new payment details. The workflow never updates a supplier's bank record. A person confirms the change with the supplier through a known contact, outside email, and updates the record themselves.
Workflow 3: approval, then the bill
The posting workflow starts when a row reaches Waiting for approval. A Human in the loop block pauses the run and shows the approver the PDF, the PO, the receipt and the match result. The approver is picked from a cost centre table, and invoices above their limit go to a second approver.
On approval, the workflow creates the bill in QuickBooks or NetSuite against the supplier and PO, attaches the PDF and writes the bill reference back to the row. On rejection, the row returns to the exceptions queue with the approver's comment. Nothing is posted until someone says yes, and the run log shows who said it and when.
Working the exceptions queue
Exceptions are the job that remains for the AP team, and the queue makes it a list instead of an inbox. Each row has an owner by reason code: quantity issues to the AP specialist for that supplier group, price issues to procurement, bank detail changes to the AP lead.
When the owner resolves the issue, for example with a credit note from the supplier or a second goods receipt, they set the row back to Received and workflow 2 matches it again. A small dashboard over the invoices table shows invoices by status, exceptions by reason and age, and how long approvals wait, so the AP lead sees where the work is stuck before month end.
Controls
Controls and governance
Approvals before action
Relays never send email or book meetings without an approval, under any autonomy setting. An approval covers the exact payload the reviewer saw and expires if nobody decides.
Audit trail
Proposals, approvals, declines and executed actions are written to the workspace audit log, which admins can export.
Run logs
Every workflow run records each block’s inputs, outputs and errors, so a reviewer can trace how a result was reached.
Deployed versions
Workflows run from a deployed version, so a change is reviewed before it reaches production runs.
Roles and permission groups
Admin, write and read roles per workspace, plus permission groups that limit which models, blocks and integrations a team can use.
PII detection
A Guardrails block detects personal data and blocks or masks it before text reaches the next step.
More on how Agent Serve handles access, data and audit on the security page.
Every run is recorded in Logs, block by block, so when a supplier asks why a bill is late, the answer is a link rather than a search. Workflows run from a deployed version, which means a change to the parsing prompt or the matching rules is reviewed before it touches live invoices. If invoices carry personal data, such as a contractor's home address, PII redaction can mask it in logs.
Start with one supplier group and a month of invoices, compare the match results with what the team decided by hand, and tune the tolerances before widening the scope. For the month-end side of AP, see closing the accruals gap.
Questions teams ask
Can the workflow pay the supplier?
This setup stops at creating the bill. Payment runs stay where they are today, with your usual sign-off. Keeping payment out of the intake workflows means a parsing mistake can never move money.
Which parser should we use?
Textract, Reducto and Mistral Parse all ship as blocks. Try each on a sample of your own invoices, including scanned ones and multi-page statements, and keep the one that reads your suppliers best. You can switch blocks later without touching the match rules.
What about invoices without a purchase order?
Utilities, subscriptions and other non-PO spend skip the three-way match. A rule routes them straight to the cost centre owner for approval, with the last three invoices from the same supplier shown for comparison.
What you need
- A shared AP inbox in Gmail or Outlook that suppliers already send invoices to
- QuickBooks or NetSuite connected, with purchase orders raised in it
- Goods receipts, either in the ledger or in a receipts table the warehouse updates
- Your written tolerances for price, quantity and total, agreed with the controller
- A list of approvers by cost centre or supplier, and an approval limit for each
- A named AP owner for each exception reason code