AP invoice automation looks simple from a distance: read the PDF, draft the bill, ask someone to approve it. The real work is keeping that process close to how AP already operates: invoices arriving in Outlook, accounting treatment following Acumatica history, and a human approving the proposed bill before anything is created.
The obvious build would have been OCR. Collect sample invoices. Train templates. Map fields. Handle exceptions. Patch the setup every time a supplier changes their PDF.
That can work when documents are stable. AP invoices are not. A cleaning supplier, a hosting provider, and a freelance contractor can all send valid invoices with completely different layouts.
Contou already had n8n in the stack, so we used it as the process layer rather than adding another one. The original brief also included Teams, but testing made the cleaner route obvious: keep Outlook as the primary AP trail. Splitting the process across chat and email would have made the audit trail worse.
The actual AP job
The workflow had to take an invoice from Outlook, draft an Acumatica AP Bill, ask for approval, and create the bill only after a human signed off.
Reading the invoice was only half the problem. The useful AP question was:
How does this company usually code this vendor?
That answer already lived in Acumatica, inside previous AP Bills.
AI reads the invoice. Acumatica stays in charge.
We used the model for the part it is good at: reading invoices with different layouts and pulling out the fields AP needs.
Everything around that was designed as normal business software:
- vendor matching is checked against Acumatica
- unclear vendors go to a human before the workflow continues
- the proposed bill is shown to an approver before anything is created
- the final bill creation is a deterministic Acumatica API call
- the original PDF is attached to the created bill
The model does not create vendors, decide approval happened, or post bills on its own. It prepares a draft. n8n handles the process. Acumatica remains the system of record.
The accounting memory was already in Acumatica
The agent does not try to infer accounting treatment from a supplier name.
For known vendors, it looks at how previous bills were handled and follows that pattern: account, subaccount, branch, project, terms, and line-level coding where available. The new invoice supplies the new facts: date, reference, description, currency, and amount.
That was the core design choice. The model reads the invoice. Acumatica provides the accounting memory.
Two review points, no black-box posting
There are two review points.
-
Vendor resolution. If the workflow cannot find one clear active vendor, the approver gets an email with the extracted supplier and possible Acumatica vendors. They choose the Acumatica Vendor ID, and the workflow validates it before continuing.
-
Bill approval. The approver gets an email that looks like it belongs next to Acumatica: compact field tables, grid-like line items, Acumatica-style colours, and the proposed bill details.
The user experience is meant to feel continuous with Acumatica. The approver does not need to know which step is the AI model, n8n, or an API call. They receive an email, check the proposed bill, and approve or reject it.
Why this was not an OCR build
A heavier OCR or ML pipeline can be cheaper per run once it is stable, but it usually costs more to set up and maintain. Every new layout becomes another configuration problem. Retraining and template upkeep become part of the operating cost.
For this workflow, flexibility mattered more. A modern document model via API gave Contou better coverage across varied invoices without locking the project into a bespoke training loop. If model quality improves later, the extraction step can be swapped or upgraded without rebuilding the AP process.
The result is less manual invoice entry, less template maintenance, and a workflow that still feels like normal Acumatica work.