Your supplier delays are sitting unread in an inbox.

Software that reads the supplier email your purchasing team receives, pulls out the order number, promised ship date, quantity and price, compares each against the matching open purchase order line in your ERP, and puts anything that disagrees in front of a buyer. It reads and matches. A person approves.

Your ERP can only alert on what is inside it. The promised date lives in an email nobody has opened, so the ERP confidently shows a date that stopped being true a week ago. The agent works the inbox first and the ERP second, which is the order the information arrives in.

No, and that is usually the point. Teams already receiving an EDI 855 acknowledgement from every supplier do not need an agent, they need better mapping. This exists for the long tail of suppliers who will never trade EDI and keep sending free-text email and PDF attachments.

Yes, that is the normal case. The agent reads the PDF, whether generated or scanned, and extracts line-level fields. Scan quality varies, so low-confidence extractions route to an exception queue for a human rather than being written into the ERP as if they were certain.

It handles the silence directly. When a PO passes your acknowledgement window with nothing back, the agent drafts a chase naming the PO, line, part number and the date you expected. The draft waits for a buyer to send it, and the missing reply is tracked as its own exception type.

Only inside limits you set, and only on fields you explicitly allow. Everything else goes to a buyer. Most teams start in propose-only mode where the agent writes nothing at all, then enable write-back on a narrow field set once they have seen how often it agrees with their buyers.

Two things catch it. Extraction confidence below your threshold means no write happens regardless of anything else, and a variance outside your tolerance rule routes the line to a person. If a wrong value does get through, every write stores the previous value and the run identifier, so the batch can be reverted.

A number deciding whether a difference is routine or worth a human. A promised date three days later than the PO might be inside tolerance and apply automatically. Three weeks later goes to the buyer. You set separate tolerances for date, quantity and price, and can set them per supplier.

Every write records the source message, extracted value, confidence score, previous value, new value, run identifier and approver. Reverting replays the previous values for one run. Because writes are restricted to an allowlist of fields, a rollback cannot disturb anything the agent was never permitted to touch.

No. The agent surfaces three-way match exceptions, meaning it shows where the purchase order, the goods receipt and the supplier invoice disagree, grouped by type. Approving, posting and paying stay with your accounts payable team inside your existing controls.

The agent flags them and never applies them. Bank detail changes arriving by email are a known fraud route, so they are a red-flag class: the message is labelled, the buyer and finance are notified, and the change waits for verification by a person using a phone number you already hold.

Not by default. Follow-ups are drafted into the buyer thread with the PO, line, part number and original date already filled in, and a person sends them. Some teams later allow automatic sending for one narrow template, usually a first chase, after watching the drafts for a while.

It becomes a range with an explicit ambiguity flag, not a precise date. Inventing precision is the failure mode that destroys trust in the field, because planners assume a date in the ERP means someone confirmed one. A flagged range tells the truth about what the supplier actually said.

It matches several signals together: the PO number in the subject or body, your part numbers, the supplier domain, quantity and value, and the set of POs currently open with that supplier. When the match is not confident it asks, because a correct date on the wrong line is worse than none.

Yes, where the link exists in your system. If a purchase order line is pegged to a work order or sales order, the alert names the exposed order, the customer and the date at risk instead of just saying a part is late. It alerts. It does not reschedule production.

Yes. Price changes are classified as their own message type, the old and new unit prices are extracted, and the variance is measured against your price tolerance and the agreed contract price where you hold one. Price movement almost always routes to a buyer, because a commercial conversation is attached.

Oracle NetSuite, SAP S/4HANA and SAP Business One, Microsoft Dynamics 365 Business Central, Acumatica, Epicor Prophet 21 and Epicor Kinetic, and Infor CloudSuite. Where a supported API exists we use it. Where it does not, the agent stays in propose-only mode and delivers a review queue instead.

Yes, and often alongside them. Requisition intake and approval routing usually belong in the source-to-pay platform, while promised dates and receipts belong in the ERP. We map which system is authoritative for each field first, because two systems both owning a date is how the current mess started.

The first useful output is usually classification and a review queue, which can run against live mail early because it writes nothing. Write-back comes later and deliberately, after a propose-only period long enough to measure agreement with your buyers. We give a firm timeline once we have sampled your mailbox.

A representative sample of real supplier email, read access to your ERP for purchase orders and receipts, your item and supplier master, your acknowledgement window and escalation rules, and one named buyer who will own the exception queue. That last one matters more than any technical item on the list.

When your open PO volume is small enough that a calendar reminder covers it, when nearly all suppliers already send a clean EDI 855, when purchasing email sits in personal inboxes instead of a shared mailbox, or when nobody can work an exception queue. We say so on the call, not after.

You do. The extraction rules, prompts, tolerance settings, field allowlist and infrastructure are yours, versioned in your repositories and running in your accounts. Tolerances and thresholds are configuration your team edits without calling us. There is no runtime you keep renting from us to keep the agent working.