OKFDE Research #001｜What AI needs to approve a purchase order
The model finds a 5% discount and gets the math right. Clara still needs to know who approved it.
KEY TAKEAWAY
Reading a discount note gives the system information to review. Before it updates a procurement record, the company needs evidence of authorization and a clear record of what was approved. The team also needs to know what to do when a write times out, so a second submission does not create a duplicate transaction.This is a fictional procurement scenario. The people, dialogue, and transactions are illustrative, not a report on a customer deployment. The technical discussion draws on the public documentation linked below. No project performance results are claimed.
Who approved the discount
A supplier’s delivery slip includes a note offering a temporary 5% volume discount. An attached chat screenshot mentions a special rate agreed earlier. The contract price in the company’s enterprise resource planning system, or ERP, is still the original price.
Leo, a forward deployed engineer working with the customer, has built an AI document review tool. It reads the item numbers, quantities, and prices correctly. It finds the discount note and the relevant chat message, then flags the price difference.
Clara, the senior order reviewer, checks the alert. The calculation is right. The message is there. She sends the order to Alex, the VP of Operations, with a question: “Was this special price formally approved?”
Alex checks the attachments. The screenshot contains a discussion about a discount, but it doesn’t establish whether the person who offered it had approval authority or whether the agreement covers this batch of parts. The order goes on hold while procurement finds the authorization record.
The model has done its part correctly. The missing information is evidence that the company can use the discounted price for this order. A more capable model would still need that evidence.
01 / What the alert should say
The tool’s original alert reads: “Special discount detected. Recommendation: Approve.”
Clara could reasonably read that as confirmation that the discount has already been authorized. The recommendation goes beyond what the tool has checked.
Leo changes it to: “Discount noted. Price differs from the contract. Approval documentation required.” He also lets Clara open the delivery slip and the full relevant conversation directly from the alert, side by side.
She can now check the extraction against the source and see what is missing. The interface gives her a way to investigate the price difference without treating the mention of a discount as approval.
The tools to locate source material already exist. Microsoft’s Document Intelligence API, for example, can return page numbers and coordinates showing where extracted content appears in an image or PDF. [1]
Those coordinates help Clara find the words. She still needs to check the screenshot’s authenticity and the sender’s authority. The interface should keep those questions visible until someone resolves them.
I would test whether the revised alert helps Clara find the supporting material faster and reduces repeated searches through the attachments. Clearer wording is a design change; its effect on the work still needs to be measured.
02 / Approval needs a defined scope
Procurement supplies the missing approval memo. Under the rules assumed in this scenario, Alex has authority to approve the price exception.
He approves the 5% discount for this batch of parts. The system can then write the approved unit price to the designated procurement record. Payment follows the company’s existing process.
A single “Approve” button would leave too much unclear. Clara confirms that the order details and attachments are complete. Alex authorizes the price exception. The system needs separate records of those actions, including who took them and what each person reviewed.
It also needs to preserve the version Alex approved. If someone changes the amount afterward, that approval should no longer authorize the changed order without another review. Otherwise, the system could apply an earlier decision to a transaction Alex never saw.
The design in this scenario calls for a protected approval snapshot and an audit history that cannot be overwritten. Cryptographic signatures and write-once storage are possible implementation choices. The requirement is to preserve the decision and its supporting evidence so that someone reviewing the transaction later can establish what happened.
Permissions also need checking when the system writes the change. A user may have been authorized when they opened the page and lost that permission while the request was waiting. Leo needs to build those checks into the execution process as well as the interface.
03 / A timeout leaves the outcome uncertain
After approval, Leo’s connector sends the price update to the ERP. The page waits, then displays a gateway timeout.
Clara is about to submit again. Leo puts the operation on hold so the team can check what happened.
A timeout tells the caller that it didn’t receive a response in time. The ERP may never have processed the request. It may also have saved the change successfully and failed to return a response. A second submission could then create a duplicate transaction, depending on how the receiving system handles the operation.
Idempotency is one way to make retries safe. An idempotent operation can be repeated without additional side effects. For an API that uses request identifiers, the caller reuses the same identifier for retries of the same operation, and the receiving system recognizes and handles the duplicate. AWS describes this approach in its Builders’ Library. [2]
That behavior depends on the receiving system’s implementation and API contract. Adding a UUID to an outgoing request does nothing if the ERP ignores it. Leo has to check what the actual interface supports.
If the system cannot establish the outcome safely, it should show “Pending verification” and route the operation to a named support team. A query that returns no record yet may still be inconclusive. The original request could be delayed, so an immediate second write may remain unsafe.
The team needs a documented way to reconcile the result and decide what happens next. Automatic retries should remain paused while the outcome is uncertain, and the page should explain why another click will not resolve it.
Holding the order has a cost too. Someone has to own the unresolved queue and work through it. Otherwise, a safeguard against duplicates can leave procurement waiting indefinitely.
04 / What I would test before release
Extraction accuracy is one part of this project. I would also want to see whether a price exception reaches the right person and whether an interrupted request leaves the system in a state the team can resolve.
I would start with historical exception orders in an isolated test environment. Keep a fixed set for evaluation, have business staff review the expected handling, and save disputed cases for further review. Simulate technical failures through test interfaces rather than experimenting with real payments.
The time measurements should separate waiting for approval from time spent doing the work. For example, if Clara saves two minutes searching for documents but spends three minutes copying the results into another system, the workflow has added work.
Then I would test the timeout directly. Have the test ERP save the change successfully but withhold the response. Ask a tester to submit again, and inspect both the target records and the status shown on the page.
If a duplicate appears, the release stays blocked. Leo needs to retain the original request record, fix the duplicate handling, and repeat the test. Where the ERP cannot support safe retries, the team needs a tested way to check the result and hand unresolved cases to a person before the system goes live.
Sources
[1] Microsoft Learn, Analyze document API response. Explains page numbers, text spans, and bounding regions in document analysis results.
[2] Amazon Builders’ Library, Making retries safe with idempotent APIs. By Malcolm Featonby. Discusses request identifiers, duplicate handling, and late-arriving requests.
ABOUT OKFDE
OKFDE is a research, engineering, and talent platform focused on Forward Deployed Engineering for enterprise AI. We turn lessons from real-world deployments into practical methods for delivering, operating, and improving AI systems.
Train. Build. Deploy.
For enterprise deployment inquiries, workshops, or field research: