Purchase Request Workflow: how to automate it

Twelve pumps have been approved. The supplier changes four of them. Eight arrive, but one is damaged. Then an invoice arrives for all eight. What has the business authorised, what can the jobs actually use, and what is still owed in delivery?

In week 20 of our case-study series, we built a purchase request workflow for Ironbark Field Services, a fictional Australian maintenance contractor. Its purchasing desk owns requests, approvals, orders, receipts and outstanding delivery commitments after a reconciled cutover. Accounting retains bills, payments and supplier bank details.

Procurify is the incumbent in this illustrative replacement scenario. SwarmCraft structured 60 tasks, implemented with Codex and followed by integration repairs and verification. The application runs on synthetic records; supplier and accounting handoffs are simulated. Artificial intelligence (AI) assistance uses deterministic source replay, not a live model. This is a demonstrated purchasing foundation, not a live customer migration.

Why own this purchasing operation?

Procurify already documents requests, approvals, purchase orders and receiving. Its intake tools include AI-guided requests and quote extraction. The replacement question is whether a focused, owned operation fits the business better once migration and maintenance are included.

That question also appears in a practitioner discussion about procurement tools. One commenter describes evaluating Procurify and starting a custom purchasing application. Others challenge the resources and support required to maintain homegrown tools. These are individual accounts, not evidence of successful replacement or a reliable cost benchmark.

For Ironbark, the boundary is job-based purchasing: one place to explain the authorised version, goods accepted and delivery still outstanding. Operational supplier references belong with that work. Bank details, tax master data, bills and payments stay in accounting because this build does not implement those responsibilities.

The purchase request process starts with the records already open

A replacement cannot begin with an empty dashboard while old orders remain outstanding. Our opening batch contains two existing orders with A$1,200 ordered, A$200 accepted and A$1,000 still to arrive. All amounts in this story are Australian dollars excluding goods and services tax (GST).

The cutover administrator stages the batch, reviews its counts and values, then activates it. Replaying the import preserves the same records rather than creating a second commitment.

The import retains source identifiers and history. Its format is invented for the experiment: we have not verified a Procurify export or migrated a real account. A customer migration would need actual export mapping, opening-balance agreement and a controlled transition that prevents two systems authorising the same purchase.

A purchase request approval workflow must preserve the version

Ironbark requests twelve pump assemblies at A$480 each, four for each of three jobs. The manager approves A$5,760. That decision belongs to the exact request, including its supplier, lines and job allocations.

The supplier can provide eight original pumps. The other four need substitutes at A$520 each, with a later delivery date. The revised commitment becomes A$5,920: an increase of A$160.

The comparison keeps the current issued amount visible while the amendment awaits review. A purchasing manager must approve the changed version before the buyer issues it. The original approval remains in history.

Responsibility follows the decision:

The server enforces these boundaries. Hiding a button is insufficient: verification also rejects self-approval, revoked authority, receiver price changes and access outside permitted jobs.

Eight arrived does not mean eight accepted

The first delivery contains eight original pumps. Seven are usable; one has a damaged housing. The receiver records both facts, leaving the damaged unit as an unresolved obligation.

Four usable pumps go to Ridgeway pump station and three to Wattle Creek maintenance. Wattle Creek still needs its replacement. Cedar Plains retrofit is waiting for all four substitutes.

Accepted value is A$3,360. Remaining delivery value is A$2,560: one original pump at A$480 plus four substitutes at A$520. The issued commitment remains A$5,920.

Those figures describe purchasing and delivery. They do not establish a payable balance or tell finance how much cash to send.

The mobile receiving view puts the physical decision first. The employee selects a job and records arrived and accepted quantities separately; the damage obligation remains visible below.

This is a useful test for purchase request automation: can the person handling the goods record what happened without turning a delivery document into proof of acceptance?

An invoice cannot repair a damaged receipt

The supplier invoice lists eight original pumps, worth A$3,840. Against seven accepted units, the desk shows a one-unit, A$480 discrepancy.

The finance reviewer can inspect the order, receipt and invoice evidence together. They cannot resolve the mismatch by silently manufacturing an eighth accepted unit. The system test rejects reconciliation while the discrepancy remains unresolved.

This makes the purchase order workflow useful beyond approval. It preserves the difference between what was ordered, what physically arrived, what was accepted and what a supplier billed.

Close the obligation without erasing the exception

Ironbark returns the damaged pump. A no-charge replacement is accepted for Wattle Creek, and the four approved substitutes are accepted for Cedar Plains. The history now contains thirteen physical arrivals, one return and twelve accepted pumps.

The damaged receipt remains visible. The replacement resolves its obligation without adding another purchase charge. Finance can reconcile the original invoice against eight accepted original pumps while retaining the earlier discrepancy.

After the simulated accounting handoff is acknowledged, purchasing can close. Accepted value is A$5,920 and remaining delivery value is zero for this order. The two imported orders still have A$1,000 outstanding.

Closure does not mean payment. It means the demonstrated purchasing conditions have been met and their evidence retained.

Where AI assistance belongs

To automate purchase requests, source assistance can prepare a draft from a quote and put proposed commercial changes beside the approved version. The operator still needs to inspect the source and make the decision.

This implementation reads permitted, structured synthetic documents, verifies their source hashes and produces draft fields with references. Manual preparation remains available. It does not demonstrate live document-reading accuracy or model reasoning.

A hostile source fixture includes instructions to approve revised terms and mark goods received. Those instructions cannot become an approval or receipt. The test establishes the application's restricted handling of that fixture, not universal resistance to model attacks. Our prompt-injection article explains why supplier content must remain evidence rather than authority.

What SwarmCraft structured and what we verified

The procurement workflow spans opening records, exact approvals, order versions, physical receipts, discrepancies, delivery recovery and history. SwarmCraft organised that work into the initial board below.

This capture records project generation. The final build manifest records all 60 tasks in Done.

Board completion did not produce a finished application. The initial delivery had unconnected browser screens and placeholder verification commands. We connected the interface to the persisted services, repaired defects and replaced those commands before capturing this article. The driver totals exclude that repair work; no complete build cost or realised saving has been measured.

The captures follow persisted checkpoints in the same synthetic purchasing journey. Additional checks cover concurrent duplicate receipts, stale writes and an accounting acknowledgement lost after delivery succeeds. Recovery finds the existing simulated effect before trying again, including after restoring pending purchasing state. An isolated database restore also preserves the completed record and approvals.

Before production, the owned foundation needs production identity, real import mapping and handoffs, deployment assurance and an accountable support owner. Corrections after closure are currently rejected; an authorised correction workflow remains unfinished. These limits matter more than a green board.

When buying remains the better answer

Run the same changed-order and damaged-delivery scenario through the incumbent before deciding to replace it. If its native workflow preserves the required evidence and fits the organisation, configuration may be simpler than operating custom software.

Our procurement software comparison and Procurify alternatives provide the buying paths. An ownership decision must also price migration, identity, hosting, integrations, recovery and ongoing maintenance. Our procurement sprawl analysis examines duplicated work; its illustrative arithmetic is not a saving achieved here.

The reusable purchase request workflow template is a sequence of accountable decisions: reconcile opening records, approve an exact version, review changes, record physical acceptance, resolve discrepancies and close with evidence. Those purchase request workflow steps define what the business must be able to explain.

Purchase request workflow automation earns its place when that explanation survives the awkward delivery as well as the straightforward one. If owning those records is worth investigating, Deep Discovery provides the source-led route through scope, controls and migration and remains in an account-enabled limited rollout.