FruxonThe clean invoices were never the problem.
Payables, PO matching, reconciliation, collections. An agent clears the records that reconcile and routes the ones that don't to the person who owns that call — with the mismatch and its reasoning already attached.
The exception queue is a person, and that person is busy.
Your OCR reads the invoice and your rules engine clears the ones that match. Everything else — the PO that's off by a line, the credit note nobody applied, the vendor whose terms changed last quarter — lands in a queue that somebody works by hand, in batches, in the last week of the month. The automation didn't fail on those. It never covered them.
What actually happens when it picks one up.
It picks the invoice up where it lands
A new document in SAP or NetSuite, a row in a queue table, a PDF in the shared Drive folder, an email to your payables address. The vendor's history and the policy that governs this spend are retrieved at the step.
It matches against the systems of record
Match the PO and the receipt, confirm the terms against the contract in Confluence, query your Postgres or BigQuery for the last three invoices from that vendor. Totals and tax are computed in an isolated Python sandbox, because arithmetic in a prompt is a guess with a decimal point.
It stops on the exception, not on the batch
A variance outside tolerance, a vendor it's never seen, an amount over the approval threshold you set. It flags that one invoice and keeps clearing the rest.
The exception goes to the person who owns it
Not to a shared payables inbox. The controller gets the invoice, the variance, the contract line it read from and the agent's reasoning on Slack, answers once, and it posts. If nobody answers, the run parks on the approval and resumes when they do.
Three things a finance queue needs that a chat product doesn't have.
One run per record, each with its own trace
Collection Pipelines map an agent across a list-style source — a table, a folder, a spreadsheet — as one isolated run per row. Each carries its own history, latency and cost, so “which invoices did it touch and what did it do to them” is a question with an answer.
Runs that survive waiting
A run can park on a human approval or a long-running operation for hours and resume where it left off instead of timing out. Every reasoning step references a named, versioned agent — no anonymous prompt buried in a graph nobody owns.
Read-only until you say otherwise
Every integration can run in Sandbox Mode: the vendor's own test environment, a stateful simulator that never leaves the platform, or read-through, where reads hit the live system and writes are captured instead of sent. Watch a month of what it would have posted before it's allowed to post anything.
Before it can post
Post the small credit. Never pay a new vendor without a signature.
Per action you decide what it does alone: handle it, ask first, or do it and tell someone afterwards. Clear the credit under a hundred, ask before anything touches a contract term, and require a human signature on the first payment to any counterparty it hasn't seen. What it can't clear goes to the person who owns that call rather than accumulating for Friday.
Approval gates on the actions that move money, each pausing the run with the full audit trail attached
Timeouts and a fallback ladder, so an invoice never sits waiting on one controller being at their desk
Tag each run with the entity or business unit it served, and get cost, error rate and p95 split per entity
It works where the invoice already lives.
Prebuilt tools for the systems your finance stack runs on — plus your own REST endpoints imported from an OpenAPI spec, and direct access to your databases when the catalogue doesn't cover it.
Slack
GitHub
Jira
Google Drive
Salesforce
MongoDB
Notion
Linear
Grafana
Discord
Google Chat
Confluence
PostgreSQL
HubSpot
Airtable
Shopify
Stripe
Datadog
Sentry
GCP
BigQuery
Slack
GitHub
Jira
Google Drive
Salesforce
MongoDB
Notion
Linear
Grafana
Discord
Google Chat
Confluence
PostgreSQL
HubSpot
Airtable
Shopify
Stripe
Datadog
Sentry
GCP
BigQuery
Google Calendar
Gmail
Mixpanel
Monday
MySQL
SAP
Zendesk
Zoho CRM
Google Maps
Google Ads
Coralogix
Telegram
Apollo
Mailchimp
Calendly
Redis
Supabase
GCP Logging
gVisor
Loops
Typeform
Google Calendar
Gmail
Mixpanel
Monday
MySQL
SAP
Zendesk
Zoho CRM
Google Maps
Google Ads
Coralogix
Telegram
Apollo
Mailchimp
Calendly
Redis
Supabase
GCP Logging
gVisor
Loops
Typeform
Don't see yours? Import tools from any MCP server.
Payables questions, answered plainly
The ones that decide whether this gets past finance and audit.
Does it replace our AP automation?
No — it works the records yours couldn't. If OCR and matching already clear most of the volume, leave them running; the agent takes the exception queue, which is where the manual hours actually are.
Can it pay an invoice?
It can post and it can trigger a payment run where you've allowed that action, always under a threshold you set. Most teams keep a permanent gate on first payments to a new counterparty, and that instinct is correct.
How do we test it against real invoices safely?
Read-through Sandbox Mode: reads hit the live system, writes are captured rather than sent. You get a month of what it would have posted, per invoice, with reasoning — before it can post anything.
Multi-entity — can we see cost per business unit?
Yes. Tag each run with the entity it served and cost, error rate and p95 split per entity, side by side. That reporting also happens to be what you need if you run payables on behalf of someone else.
IT & Employee Support
Access requests, provisioning, and the same question asked forty ways — with a gate on anything that grants permission.
Order & Fulfillment Ops
Order exceptions, addresses that won't parse, inventory that doesn't line up, returns and replacements.
Someone's waiting
Support, success, onboarding — the work with a customer waiting on it.