AI Agents for Plex
Accounts Payable
The AP exception queue at a manufacturer is mostly a record of what happened in receiving, and Plex already captured all of it.
- Partial receipts are normal at a manufacturer, not exceptions. A matcher expecting one receipt per invoice fails a large share of a perfectly healthy population.
- Material received and quarantined is a different state from material not received. Describing a held invoice as awaiting inspection routes it to quality rather than leaving it in the finance queue.
- In an illustrative population of 187 unmatched invoices, not a customer figure, 19 come from one part with a unit of measure mismatch. One master data fix ends all nineteen, every month.
- Unit of measure errors are proportional, so they grow with volume and read as price variance. Check the order unit against the receipt unit before attributing a difference to price.
- Landed cost arriving after the stock was sold cannot be capitalised. Report the share of freight and duty relating to prior period receipts, and how much of it has already gone.
AI agents for Plex accounts payable read the purchase order, the receipt history and the quality status together, match invoices against partial receipts and supplier tolerances, and group what fails by pattern rather than by value. ChatFin reads through the Plex Connect REST API at transaction level and prepares work for a person to approve.
On Plex, unlike most general purpose ERPs, the evidence is already there. Plex records receiving in detail, including partial deliveries, container or lot references and quality hold status, and almost none of that reaches the person working the AP exception queue. In the illustrative month worked through below, which is not a customer figure, 90 of 187 unmatched invoices need no human decision and 19 come from a single part with a unit of measure mismatch.
On a manufacturer, payables starts at the receiving dock
The AP exception queue at a manufacturer is mostly a record of what happened in receiving. Plex captures receiving in detail, which means the evidence to resolve most exceptions already exists and is not being read by anyone in finance.
ChatFin reads the receipt history and the quality status together, so a held invoice is described as awaiting inspection rather than as unmatched. Those are different problems with different owners.
What an agent reads on Plex
Most of this comes through the Plex Connect REST API: purchase orders and their lines, receipts, AP invoices, AP payments and general ledger transactions. Access needs Plex IAM activated and an app key from the Plex developer portal, and most of the APIs allow 200 calls a minute. AP invoice lists return about 1,000 invoices per call, linking receipts to an AP invoice takes up to 300 receipts per call, and the API can create AP invoices. Standard cost is not in the catalogue and comes through Plex data sources or ODBC. Quality hold status and unit of measure conversions are not among the finance APIs, so confirm during scoping which API or data source your tenant exposes for them.
| Area | What payables needs | Why |
|---|---|---|
| Purchase orders and lines | Ordered quantity, price, unit of measure | The authority for what was agreed |
| Receipts | Quantity, date, container or lot, quality status | Where a partial or held receipt is explained |
| Supplier master | Terms, remittance detail, quality rating | Resolution target, and duplicates here cause most downstream mess |
| Part master | Standard cost, unit of measure conversions | Where a unit of measure error becomes a price variance |
| General ledger | Posted result by account and period | The tie back, in both directions |
Unit of measure is the field that repays attention. Purchased in cases, stocked in each, consumed in kilos, and each conversion is a place a factor can be wrong. The error is proportional, so it grows quietly with volume and reads as a price problem.
ChatFin reads quantity and value on the same row and checks the unit of measure on the order against the receipt before it attributes a difference to price.
An illustrative match failure population, 187 invoices
Take an illustrative month, not a customer figure, that leaves 187 supplier invoices unmatched. Sorted by value that is 187 investigations. Grouped by pattern it is six, and one of them is a single master data fix that has been producing exceptions for months.
| Pattern | Invoices | Where it goes |
|---|---|---|
| Partial receipts, invoice covers several | 61 | Auto match on the aggregate, no person needed |
| Material received, still in quality hold | 38 | Quality, with the lot and hold reason |
| Overshipment inside the supplier tolerance | 29 | Auto match on the rule, name the rule |
| Price above the order, outside tolerance | 24 | Procurement. A contract question |
| Unit of measure mismatch on one part | 19 | Master data. One fix ends all nineteen |
| Invoice against a closed order | 16 | Requisitioner, to confirm the receipt happened |
The fifth row is the one worth finding. Nineteen exceptions on a single part, every month, because a purchase order unit and a stocking unit disagree. Nobody finds it because nobody groups the population by part.
Freight, duty and the invoice with no purchase order
Landed cost invoices have no order line to match to, which makes them the population most likely to be coded to a default account and forgotten.
Tie the freight invoice back to the shipment it relates to
The carrier reference, the container or the delivery note. This is the link that makes the cost attributable rather than periodic.
Decide the allocation basis once and hold it
By value, by weight or by unit gives three different product margins from one shipment. Choosing per shipment makes margin analysis meaningless.
Report what arrived after the goods were consumed
Landed cost for stock already sold cannot be capitalised. It hits cost of sales and the margin on that sale is wrong permanently.
Accrue for shipments received and not yet invoiced
Freight and duty are predictable from the shipment. Leaving them out understates inventory cost every period end.
Accruals a manufacturer can actually calculate
Received not invoiced is knowable exactly at a manufacturer, because receiving is recorded transaction by transaction. It is still usually estimated, because working it spans three sources.
Take receipts with no matching invoice at the cut off
Read receipts against supplier invoices on the same order line. What remains is the population, and it is a fact rather than a judgement.
Price from the purchase order, not from standard
The committed price is on the order. Using standard cost turns a calculable number into one that has to be defended, and it double counts purchase price variance.
Add freight and duty expected but not yet billed
Predictable from the shipment. Leaving it out understates inventory cost every period.
Separate the aged tail and name it
Receipts older than a quarter with no invoice are a process failure rather than timing, and reporting them as accrual hides that.
Prepare the entry, do not post it
The agent produces the journal with the receipt documents attached. A named person reviews and approves it, and only then is it written to Plex.
ChatFin lists the receipts behind every accrual line, so the review is of a population rather than a total. Where a receipt has no order price it says so rather than substituting one.
Where this underperforms on Plex
Three, and all three are upstream of the agent.
ChatFin is additive to Plex rather than a replacement for receiving, quality or purchasing workflow. Where Plex already handles a case cleanly there is no reason to put an agent in front of it.
Deeper in Plex payables
Three use cases sit under this hub, in build and shown rather than linked.
Worked on this page
Vendor follow up for missing invoices · AP inbox automation · Invoice intake and document extraction
Covered as sections here
3 way matching · Partial receipts · Quality holds · Landed cost · Duplicate detection · GL coding
Questions manufacturing payables teams ask first
Why do so many invoices fail matching at a manufacturer?
Usually because the match logic expects one receipt per invoice and manufacturing does not work that way. A purchase order line received across four deliveries produces four receipt records against one invoice, and overshipment inside a supplier tolerance is deliberate rather than an error. ChatFin matches against the aggregate receipt history and names the tolerance rule it applied, so a healthy population stops arriving in the exception queue.
What is the difference between an unmatched invoice and one on quality hold?
The owner. Material received and quarantined is physically present and not yet acceptable, which is a quality decision with a lot number and a hold reason attached. Material not received is a receiving or supplier question. Describing both as unmatched puts them in the same queue, worked by the person who can resolve neither. ChatFin reads the quality status alongside the receipt and routes accordingly.
How does a unit of measure error show up in payables?
As a price variance, which sends the investigation the wrong way. Purchased in cases, stocked in each and consumed in kilos means every conversion is somewhere a factor can be wrong, and the error is proportional so it grows with volume rather than appearing suddenly. In the illustrative population on this page it produces 19 exceptions on one part. ChatFin checks the order unit against the receipt unit before attributing any difference to price.
Exceptions grouped into patterns, with the permanent fix named.
ChatFin reads the purchase order, the full receipt history and the quality status together, matches against partial deliveries and supplier tolerances, and names the rule it applied.
Exceptions are grouped by pattern and routed to quality, procurement, receiving or master data. ChatFin approves nothing.
Bring one month of match failures.
Book a demoAll images are served from the Pexels content network. No third party product screenshots, vendor logos or licensed media are used on this page.
Bring one month of match failures.
We will run the same population through ChatFin, group it by pattern rather than value, and show you which exceptions come from one master data record.