New: what governed autonomous procurement actually means
Proconomy
Log in See Proconomy in action
Workflow demonstration

Governed intake to ERP purchase order

In short

A plant raises a free-text request. An agent interprets it, collects the missing detail, applies the buying policy, routes approval to the authorised person and writes the approved purchase order back to ERP, leaving a complete action history.

Request a workflow demonstration Watch an autonomous workflow

Trigger

A maintenance engineer emails a request for a replacement drive unit.

Relevant audience

CPO, CIO, buyers and procurement transformation

Stage by stage. With the control that applies.

  1. Stage 1 — TriggerTrigger
    An unstructured plant request arrives
    Free text, no specification reference, a required date and an urgency claim.
    What stays in control
    The request enters a governed record immediately.
    Outcome
    The request stops depending on a buyer’s inbox.
  2. Stage 2 — Agent actionAgent action
    The agent interprets the request
    Category, plant, entity, cost centre and estimated value band are extracted from the text.
    What stays in control
    Extracted values remain visible and correctable.
    Outcome
    No manual triage before work can begin.
  3. Stage 3 — Agent actionAgent action
    Missing information is collected
    The agent asks the requester for the equipment reference and confirms the required date.
    What stays in control
    The request cannot progress while required fields are absent.
    Outcome
    The buyer receives a complete request rather than a partial one.
  4. Stage 4 — PolicyRule applied
    The buying policy selects the route
    The value falls under an existing supply agreement, so the request becomes a contracted purchase rather than a sourcing event.
    What stays in control
    The rule that selected the route is recorded.
    Outcome
    Consistent process selection without manual policing.
  5. Stage 5 — Human decisionHuman decision
    Financial authority approves
    The plant approver receives a complete request with contracted pricing already applied, and approves within threshold.
    What stays in control
    Approval authority follows your delegation of authority.
    Outcome
    Approval becomes a decision rather than an investigation.
  6. Stage 6 — System updateSystem updated
    The purchase order is created in ERP
    The approved outcome is written back with the correct plant, cost centre and contracted price.
    What stays in control
    Write-back success is monitored; failure would be raised as an exception.
    Outcome
    No re-entry and no transcription error.
  7. Stage 7 — Audit historyRecorded
    The full history is retained
    Original text, extracted data, applied rule, approval and resulting ERP transaction stay linked.
    What stays in control
    Audit can reconstruct why the request took this route.
    Outcome
    Evidence without a separate tracker.

Six questions. Answered the same way every time.

Every Proconomy workflow demonstration answers the same six questions, so you can set one workflow against another and against how it runs today.

QuestionAnswer
What triggered the workflow?A free-text maintenance request from a plant engineer.
What did the agent do?Interpreted the request, extracted procurement data, collected the missing equipment reference and applied contracted pricing.
What rule permitted it?A buying policy rule routing in-contract requests under the plant threshold to a contracted purchase.
What returned to a person?Financial approval by the plant approver within their delegated authority.
What system was updated?The ERP, with a purchase order carrying the approved values.
What outcome changed?Less manual coordination, faster request handling and preserved authority.

What changes as a result. Named, not implied.

  • Less triage and approval chasing.
  • Faster service to the plant.
  • Preserved financial authority.
  • ERP coexistence with no manual re-entry.

See all workflow demonstrations

Action history · request REQ-88214 Illustrative
Request interpreted and classified
Intake agent09:12:04INTAKE-04
Missing equipment reference requested
Intake agent09:12:09INTAKE-04
Requester supplied reference GB-4417
R. Mehta09:41:22—
Buying policy selected contracted purchase
Policy engine09:41:24POL-BUY-12
Approved within delegated authority
S. Iyer · Plant controller10:06:51DOA-B2
Purchase order written back to ERP
Integration service10:06:58PO-118322
RecordedRetained for the period your retention policy defines

How this runs today. Mostly coordination, not judgement.

What happens between the need and the outcome, in most groups.

The request arrives as prose
An email describing a problem, not a requirement. Someone has to read it and decide what it actually is.
A buyer classifies it
Category, entity, cost centre and value band worked out from experience rather than from a rule.
Missing information is chased
A drawing reference, a delivery date, a budget code — each one a separate email and a separate wait.
The route is chosen from memory
Catalogue, contract, sourcing or onboarding, decided by whoever opened the inbox that morning.
Approvals are chased individually
Sequentially, by email, with no visibility of where it has reached.
The outcome is retyped
Into the ERP, by hand, which is where the transcription errors come from.
Status is answered by asking
The requester emails the buyer, who checks and replies. Repeatedly.

Six things to watch for.|In any vendor session.

  1. Give them a genuinely ambiguous request, not a clean one. Watch what the system does when it cannot classify confidently.
  2. Ask to see the stored reference for the rule that selected the buying route.
  3. Remove a required field and confirm the request cannot progress.
  4. Ask what happens when the approver is on leave.
  5. Ask what the system did overnight, unattended.
  6. Make them fail the ERP write-back deliberately and watch who is told.

Four things to bring.|Yours, not ours.

  • One real request that went badly — ideally with the email thread.
  • Your approval matrix as it actually operates, not as the document describes.
  • The category list for the plant or entity involved.
  • Whoever can settle a process question without convening a committee.

Request this demonstration →

Bring one real workflow. We will run it, exceptions included.

These sequences describe the operating model. A live demonstration on your own process shows it, including the point where the software stops and asks a person.

Request a workflow demonstration See Proconomy in action

Someone from client success replies, not a sales sequence. If we are not a fit we will say so on the first call.

Not ready to talk to anyone?

Fair enough. Both of these work without giving us your email.