Finance areas · Payables & accounting
Vendor bills, journal entries, recurring postings and payment batches run as governed transactions on a real double-entry ledger. Your team approves what policy says needs approving; agents do the extraction, matching, posting and chasing.
The whole payables surface
01 / The lifecycle
Six stages, one record of what happened at each. Nothing is written until the dry-run passes and your policy says it may proceed.
Forwarded by email, dropped in chat, or synced from a connected system — classified and routed automatically.
Amounts, tax treatment and expense accounts are extracted and checked against your vendor master data. New vendors become proposals, never silent records.
The proposed posting is validated against real ledger state — accounts, periods, balances — before anything is written.
Recognised low-risk bills execute in the lanes your policy defines; unusual ones wait for the reviewer your rules require, with the full trace attached.
One of the ledger's typed transactions, not a free-form entry. Every line keeps its source document.
The Payment Proposal agent builds batches from what's due, approvals release them, and the bank's confirmation settles the bills.
Every posting is a typed transaction on a double-entry ledger — dry-run, risk-routed and audit-trailed like everything else.
02 / Coverage
From the purchase order to the payment. Bills, master data, missing documents and assets run on the same ledger and the same controls.
Raise a PO by asking Claude, record the goods receipt, and the Bill Processor matches the incoming bill against the PO when one exists.
Email, upload or sync — extracted, validated against master data, and posted with the source document attached.
Manual and recurring entries as governed transactions — balanced, period-checked, and traceable.
Vendors, accounts and payment terms proposed and maintained by agents, with human approval where your policy requires it.
Due bills collected into proposals, approved, transmitted to the bank, and confirmed against the statement.
A bank line without a bill triggers a chase to the vendor — an agent's job, not your team's.
Asset purchases spotted on bills become fixed-asset records with depreciation schedules — proposed, not assumed.
03 / Who does the work
Each one has a job description, an audit trail, and limits your policy sets.
Reads vendor bills from email, extracts the data, resolves the vendor, classifies the lines, and drafts the AP invoice for approval.
Below-threshold extractions are sent to a human review panel instead of being posted. Missing vendors are delegated to the Master Data Agent; missing posting profiles to the Configuration Agent.
Builds payment batches from outstanding AP invoices and approved expense reports, grouped by method, currency, and source bank.
Produces a proposed batch only. A human reviews every line against its bill and approval, then approves and transmits the bank file. No agent moves money.
Finds paid vendor transactions that are missing their bill and sends escalating documentation requests to the business.
Creates fixed asset records from capitalized AP purchases and schedules depreciation.
Currently disabled in configuration. The capability is built; asset creation is handled manually until it is re-enabled.
Not limited to four
Accountants describe the work to Claude in plain language — what starts it, what to check, when to ask a person. Claude turns it into an agent with its own triggers, steps and limits, running under the same controls and audit trail as the four above.
04 / Tasks
Agents don't guess. What they can't resolve becomes a task for the right person, with the evidence attached. Approvals and agent requests arrive in one task list.
Confidence on two line items is below your threshold, so the bill isn't posted. The source PDF and the proposed coding are attached.
You correct or confirm; the agent posts and remembers the pattern.
A proposed batch of due bills, grouped by bank and currency. Every line links to its bill and its approval.
You approve and transmit the bank file. No agent moves money.
The vendor was created from a bill, but the bank account is unknown. The field is flagged, so nothing is sent or paid to a placeholder.
You fill it in; the blocked payment continues.
Agents hand work to each other first — an unknown vendor goes to the Master Data agent, missing setup to the Configuration agent. Anything still unclear reaches a person after two hops at most.
Payments stay human
The Payment Proposal agent builds batches from what's due. A person reviews every line against its bill and approval, then approves and transmits the bank file. The bank's confirmation settles the bills.
05 / Go deeper
Start with this workflow
Run a month of vendor bills in shadow mode beside your current process — compare touches, cycle time and exceptions before anything posts.
hello@ar-ti-fi.com