AP invoice automation is the workflow where an AI agent's ROI is easiest to prove and easiest to get wrong: the volume is high, the format variance is real, and the cost of a wrong number reaching a payment run is unacceptable. The architecture that works treats the LLM as an extraction and classification layer, never as the thing that decides what gets paid.
The pipeline: extract, match, flag
A working AP automation agent has three stages. First, extraction: a vision-capable model (or a dedicated OCR service) pulls vendor name, invoice number, line items, and totals from a scanned or emailed PDF into structured JSON. Second, matching: deterministic code — not the LLM — looks up the vendor in Acumatica, checks for an existing PO via the REST API, and attempts a three-way match against the PO and receipt. Third, flagging: anything that doesn't match cleanly (price variance, missing PO, duplicate invoice number) gets routed to a human queue instead of auto-posted.
from anthropic import Anthropic
client = Anthropic()
resp = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=1024,
messages=[{
"role": "user",
"content": [
{"type": "document", "source": {"type": "base64", "media_type": "application/pdf", "data": pdf_b64}},
{"type": "text", "text": "Extract vendor name, invoice number, invoice date, "
"line items, and total as JSON. If a field is unclear, "
"return null rather than guessing."}
]
}]
)Why extraction should never decide payment
The extraction step's output is a proposal, not a fact. Once the JSON comes back, deterministic validation code checks the total against the sum of line items, checks the vendor exists in Acumatica's vendor master, and checks the invoice number hasn't already been posted — all things a regex and a database lookup do reliably and an LLM does not. Only after those checks pass does the bill get created as a draft in Acumatica via the AP Bill entity, still unreleased, still requiring a human to approve.
If the extracted invoice is missing a field, the correct behavior is to flag it for human review, not have the model infer a plausible value from the vendor's historical pattern. An LLM asked to "fill in a reasonable amount" will do so confidently and wrongly often enough to matter when the number represents real money leaving the business.
The three-way match in Acumatica terms
Acumatica's AP module already models the PO, the receipt, and the bill as linked entities — the automation's job is to fetch all three via the REST API for a given PO number, compare quantities and unit prices programmatically, and only auto-approve the bill if the variance is within a configured tolerance (commonly a few percent, tuned per client). Anything outside tolerance routes to an approver with the discrepancy highlighted, not buried in a wall of extracted text.
Measuring whether it's working
Track straight-through-processing rate (invoices that reach a posted bill with zero human touches) separately from extraction accuracy. A model can have excellent field-level accuracy and still have a low straight-through rate if your matching tolerances are too strict — and a high straight-through rate with sloppy accuracy is worse than no automation, because errors compound silently.
Wrapping up
The AI part of AP automation is genuinely useful for turning unstructured PDFs into structured data. Everything downstream of that — matching, tolerance checks, approval routing — should be the same boring deterministic logic you'd write without an LLM in the picture at all. If you are stuck on something specific, reach out or keep reading through the rest of the Acumatica blog.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.