Build an invoice processing agent

Your finance team spends 12 hours per week on invoice data entry.

They open PDFs, type vendor names into NetSuite, enter line items, match to purchase orders, route for approval, post to the GL on approval, file the PDF in the right folder. The work is mechanical, error-prone, and recurring. Every month it happens again.

Invoice processing is probably the most automatable workflow in finance, and almost nobody has automated it. Not because the technology was missing. Because the off-the-shelf tools cost too much per invoice or required enterprise contracts most companies couldn't justify.

In 2026, the build is a few days with Avery NXR. The math has flipped. This post is the build.

The full invoice processing workflow

Strip down what a finance team actually does with each invoice and the workflow has six steps.

Email arrives with the invoice attached as a PDF, sometimes inline in the body.

Someone opens the PDF and reads the relevant fields: vendor name, invoice number, invoice date, due date, total amount, line items, tax breakdown, payment terms.

That data gets typed into the ERP (NetSuite, QuickBooks, Xero, SAP, whatever the company uses).

The system looks up the matching purchase order. The line items are matched against the PO. Discrepancies get flagged for human review.

The invoice routes for approval based on amount thresholds. Under $1,000 might auto-approve. Over $10,000 might need the CFO. Custom rules for capex vs opex, departmental budgets, etc.

On approval, the invoice posts to the GL. The PDF gets filed with the invoice record for audit purposes.

For a company processing 200 invoices per month, this workflow consumes a meaningful fraction of a finance person's time. The agent does 90 percent of it automatically.

What the agent does

The agent handles the mechanical parts. The human handles the exceptions.

Email watching. The agent monitors a specific inbox (invoices@company.com or similar). Each new message gets processed.

PDF extraction. The agent reads the PDF and extracts the structured data. Modern local models handle this with high accuracy for standard invoice formats.

Vendor matching. The agent looks up the vendor in the ERP by name and tax ID. New vendors trigger a flag for human review and setup.

PO matching. For invoices referencing a PO, the agent pulls the open PO from the ERP and matches line items. Within-tolerance matches proceed automatically; significant discrepancies flag for review.

Approval routing. Based on amount and category rules, the agent routes for the right approvals. Email notifications go out. Approvers see the invoice and the matched PO in one view.

GL posting. On approval, the agent posts to the GL with the right account coding (which can be inferred from the vendor profile or the PO).

Audit logging. Every step logged. Vendor lookups, extraction results, matching decisions, approval flow, posting confirmation. SOX-friendly and external-auditor-friendly.

That's the full workflow. The human steps in for exceptions: new vendors, significant PO discrepancies, approvals, and anything the agent flags as uncertain.

The Avery NXR build

CR 1: Email watcher and ingestion.

"Build an IMAP watcher for ap@company.com that runs continuously. On new email, parse subject, sender, body, and attachments. Store as Invoice record with status 'new'. Save the PDF attachment to S3 with a deterministic filename. If multiple PDFs in one email, create separate Invoice records for each. If non-PDF attachment, flag for human review."

CR 2: PDF text extraction.

"Build a PDF extraction step. For each Invoice in 'new' status, extract the text and image content. Use a robust PDF library (pdfminer.six or pdf-parse) for text-heavy invoices. For image-heavy invoices, fallback to OCR via local Tesseract. Store extracted text in InvoiceText table. Update Invoice status to 'extracted'."

CR 3: Structured data extraction.

"For each Invoice in 'extracted' status, run the local model with a structured extraction prompt. Output a JSON object with: vendor_name, vendor_tax_id, invoice_number, invoice_date, due_date, line_items (array of {description, quantity, unit_price, total}), subtotal, tax_total, grand_total, payment_terms, po_number (nullable). Validate the output against expected types. Store as InvoiceExtracted table. Flag invoices where extraction confidence is low for human review."

CR 4: Vendor matching.

"For each Invoice with structured data, look up the vendor in the ERP (NetSuite). Match by vendor_tax_id first, then by fuzzy name match against the vendor master. If exact match found, link the Invoice to the vendor. If no match, create a 'pending vendor setup' task and notify the finance lead. If fuzzy match found, flag for human verification before linking."

CR 5: PO matching.

"For each Invoice with vendor linked and po_number populated, fetch the open PO from NetSuite. Match line items by description and quantity (with fuzzy matching for descriptions). Calculate variance for each line. If total variance is under 5%, mark as matched and proceed. If variance is over 5%, flag for human review with the line-by-line breakdown."

CR 6: Approval routing.

"For each Invoice that's matched and ready, route based on approval rules. Build an ApprovalRule model: condition (amount threshold, category, vendor type), approver_id, priority. Evaluate rules to determine the right approver. Send email notification with the Invoice details, PO match, and one-click approve/reject. Track approval status."

CR 7: GL posting.

"On approval, post the Invoice to the NetSuite GL with the right account coding. Use the vendor profile default accounts unless overridden by the approver. Mark the Invoice status as 'posted'. Send confirmation to the requester. Generate a posting audit log entry with timestamp, approver, GL accounts hit, and total."

CR 8: Audit log and dashboard.

"Build /admin/invoices/audit showing all invoice processing events. Filterable by date range, vendor, status, approver. Each Invoice has a detail view showing the full timeline (received, extracted, matched, approved, posted) with timestamps and who took each action. Export to CSV for external audit support."

That's the complete system. Eight CRs, three to four focused days for a team familiar with their ERP's API.

The audit trail is the unsung hero

Finance teams care about audit logs more than any other team I've worked with. The reason: SOX, external audit cycles, and the personal liability that comes with controllership roles.

A complete audit trail makes auditors' lives easier. Auditors who like working with you give you better outcomes.

The audit log structure I'd recommend:

Each Invoice has a complete event history: received, extracted, vendor matched, PO matched, approval requested, approval received, posted, paid.

Each event captures who (system user or human), when (precise timestamp), what (action taken), and why (rule applied or human reason if provided).

The log is append-only. No edits, no deletes. If a mistake needs correction, the correction is itself logged as a new event.

External audit can be served by exporting the log for a date range. SOX 404 evidence is the log plus the documented control procedures.

This level of auditability is hard to retrofit. Building it in from the start is the right pattern.

The accuracy reality

Local models extract structured data from standard invoices at 95+ percent accuracy after some prompt tuning. The remaining 5 percent are the weird formats: handwritten invoices, foreign-language invoices, partial scans, invoices that are really receipts pretending to be invoices.

Build a human-review queue for the 5 percent. Don't try to automate them. The cost of getting them wrong (paying the wrong amount, paying the wrong vendor, coding to the wrong account) exceeds the cost of human review time.

For the 95 percent automated path, the failure modes are:

Vendor matching ambiguity. The invoice says "ABC Corp" but the master has both "ABC Corp" and "ABC Corporation." Default to flagging rather than guessing.

PO line item description mismatch. The PO says "professional services" and the invoice says "Q1 consulting." Fuzzy matching catches most; the rest go to human review.

Amount discrepancies. The invoice says $5,250 and the PO says $5,000. Tolerance-based handling: under 5 percent variance auto-proceeds; over 5 percent flags for review.

These failure modes are predictable. The audit log catches anything that slips through.

The cost comparison

For a company processing 500 invoices per month:

Manual processing: a few hours per day of finance team time. Real cost in salary plus the opportunity cost of work that finance person isn't doing.

Off-the-shelf automation tools (Bill.com, Tipalti, Stampli, others): per-invoice fees that scale with volume. For 500 invoices per month, real monthly cost. Plus the cost of integration to the ERP.

Custom local agent: build cost (one time), plus the workstation running Avery NXR, plus the audit infrastructure. After the one-time investment, near-zero recurring cost.

The break-even versus off-the-shelf tools is typically under six months. The break-even versus manual processing is even faster.

Why local-first matters for invoices specifically

Invoices contain sensitive vendor data. Pricing terms. Volume discounts. Payment terms. Sometimes contractual language.

If your vendor agreements are confidential (most are), sending the invoice text to a cloud AI provider for processing creates exposure. Your vendor probably didn't agree to their pricing being shared with OpenAI.

Local-first processing keeps everything in your environment. The vendor data stays where it should. The compliance posture is clean.

For companies with strict procurement and vendor management policies, this is the difference between "we can use AI for this" and "no, security said no."

Integration patterns by ERP

The biggest implementation effort is the ERP integration. Each system is different.

NetSuite: SuiteScript or RESTlets for read/write access. SuiteCloud Platform for the heavier integrations. Custom records for the audit log.

QuickBooks: REST API for QuickBooks Online. Pretty clean. Webhooks for some events.

Xero: REST API, OAuth2 authentication. Clean API design relative to enterprise ERPs.

SAP: more complex. Probably integrate via SAP's standard interfaces (RFC, BAPI) or a middleware layer.

Microsoft Dynamics: REST API. Similar effort to NetSuite.

Budget half a day to a day for the ERP integration depending on which system. Have someone who knows the ERP's API.

What this doesn't do

Worth being honest about the boundaries.

The agent doesn't replace your accountant's judgment on complex transactions. Capitalize vs expense, accruals at period close, transfer pricing, all still need human judgment.

The agent doesn't handle invoice disputes. When a vendor sends a wrong invoice, you push back, the vendor revises, and the cycle continues. The agent processes what's submitted; the dispute is a human conversation.

The agent doesn't replace your ERP. NetSuite/QuickBooks/etc. stay as the system of record. The agent is the layer that automates the data entry into the ERP.

The agent doesn't make payment decisions. Approved invoices flow to your payment process (manual check writing, ACH batches, Bill.com, whatever). The agent ends at "posted to GL"; payment is separate.

The v1.1 additions

Once the core system is shipping, the obvious extensions:

Three-way matching. Match invoice against PO and goods receipt (for physical goods). Reduces fraud risk and ensures you only pay for what was actually delivered.

Recurring invoice detection. SaaS subscriptions, monthly services, utilities. The agent recognizes recurring patterns and auto-approves when the amount matches the expected value.

Vendor portal. Self-service portal where vendors can submit invoices, check payment status, and update their tax info. Reduces the email-based intake friction.

Cash flow forecasting. With clean invoice data flowing in, build a forecasting model that predicts your cash needs over the next 90 days.

Tax compliance. For US, handle 1099 vendor identification and reporting. For VAT/GST jurisdictions, handle the input tax credit tracking.

Each is a separate CR set. Ship the core first. Add incrementally.

Implementation timeline

For a typical finance team deploying this:

Week 1: hardware setup, Avery NXR install, basic CR scoping with finance lead.

Week 2: CRs 1-3 (email, PDF extraction, structured extraction). Test on real invoice samples.

Week 3: CRs 4-5 (vendor and PO matching). Integration with the ERP.

Week 4: CRs 6-8 (approval, posting, audit). End-to-end testing.

Weeks 5-6: parallel running with manual process. Catch and fix failure modes.

Week 7: cutover. Manual process becomes the exception handler.

Six weeks to live. ROI starts immediately.

The closing thought

Invoice processing has been the obvious automation target for decades. The reason it stayed manual at most companies is the cost-effort calculus didn't work. Build was too expensive. Off-the-shelf was too expensive in a different way. Manual was painful but cheaper than the alternatives.

In 2026, the math works for custom builds. Avery NXR processes invoices reliably, the integration to your ERP is doable, and the audit trail satisfies your finance leadership.

If your finance team is spending hours per week on data entry, the build pays back in the first quarter.

avery.software