Reading an invoice is only half of AP invoice automation.
A document model can usually find the supplier name, invoice number, date, currency, descriptions and totals. It cannot learn from the PDF alone how a particular business normally treats that supplier in Acumatica.
That context often exists already. It sits in previous AP Bills: the vendor record selected, account and subaccount used, branch, project, payment terms and the way individual lines were coded.
Use the new invoice for new facts and Acumatica for operating context. The model has no reason to recreate accounting knowledge that already exists in the ERP.
Separate new facts from existing treatment
An incoming invoice contains facts about this transaction:
- who issued it
- the reference and dates
- what was supplied
- the currency, tax and total
- the line descriptions and amounts
Acumatica contains a different kind of evidence: how the business has handled comparable transactions before.
Those two sources should remain visibly separate. The invoice extraction should not quietly invent an account because a supplier name sounds familiar. The historical lookup should not overwrite a changed amount, date or description because the previous bill looked similar.
This separation also makes failures easier to understand. If the total is wrong, inspect the extraction. If the coding is wrong, inspect the vendor match, historical selection and business rules. Without that distinction, every correction becomes “the AI got it wrong”, which tells the team nothing about what needs repairing.
Use history to narrow the proposal
Previous bills show past treatment, including its exceptions and outdated choices.
One bill may have been an exception. A supplier may work across several branches or projects. Coding may have changed after a contract renewal, chart-of-accounts update or internal reorganisation.
A dependable workflow should therefore look for comparable recent records and test whether they agree. The checks include:
- Is the proposed vendor active and unambiguous?
- Do recent bills use the same account and subaccount consistently?
- Does the branch, company or project match the current invoice context?
- Are there several plausible treatments that require a person to choose?
- Has anything material changed since the precedent bill?
Where history is consistent, it can remove repetitive entry. Where it conflicts, the conflict is the result the approver needs to see.
Show the approver where each value came from
“Human approval” is weak if the human receives an opaque form filled with plausible-looking values.
The review should distinguish between:
- fields extracted from the new invoice
- the matched Acumatica vendor
- coding proposed from previous bills or current vendor defaults
- missing or conflicting information
- the exact AP Bill that will be created if approved
The approver should be able to correct the proposal or reject it without reconstructing the whole transaction from scratch. If vendor resolution is uncertain, that decision belongs before final bill approval rather than being buried inside it.
In AISI’s Acumatica-native AP invoice workflow, vendor ambiguity and bill approval are separate review points. The model reads varied invoice layouts, while Acumatica remains the source of vendor and accounting context. Bill creation happens through a deterministic API call only after approval.
Aleks discusses the same division between model interpretation and ordinary software in his ERP SEAL Podcast conversation.
Know when history becomes unreliable
Historical treatment is least reliable when the business is deliberately changing:
- a new vendor relationship
- a new entity, branch or project
- revised tax treatment
- a one-off capital purchase
- a contract or service that spans several coding categories
- poor-quality historical data that the team already knows needs cleaning
Route these cases into a clear exception path.
The workflow can still extract the invoice, locate possible vendors and assemble the relevant context. It should then stop pretending that repetition is certainty and ask for the accounting decision it cannot safely make.
Keep the system of record in charge
Acumatica should remain the accounting memory for AP automation.
Use the model where document variation makes rigid extraction expensive to maintain. Use Acumatica for the records and rules the business already relies on. Keep the proposal traceable to both, and let a responsible person decide when the evidence does not line up.
That division of labour is less dramatic than asking an agent to code invoices by instinct. It is also much easier to operate, and it does not require an expert LLM.