Internal catalog
- Contract items and prices per supplier
- Search, favorites and bundles
- Prices kept in step with the contract
Purchase Order Software
Purchase order software for procurement teams
Requests arrive by email, approvals happen in chat, and nobody can say how much of the budget is already committed. Agnotic Technologies builds purchase order software that takes a request from catalog or punchout through budget check, approval and PO issue to the goods receipt.
Catalogs and cXML punchoutBudget checksApproval rulesChange orders and receipts
Trusted by global innovators
Requisition to receipt
What is purchase order software?
Purchase order software turns a requisition into an approved purchase order and tracks it until the goods or services are received. Agnotic Technologies builds purchase order software for procurement teams: catalog and punchout buying, budget checks and commitments, approval rules, PO issue to suppliers, change orders and goods receipt, connected to your ERP.
The page stops at the receipt. Supplier onboarding and risk sit on our vendor management platform page, EDI volumes and partner maps on our supply chain EDI integration page, and invoice matching on our invoice processing automation page.
A purchase order commits budget before it is a document for the supplier. Most of the design work is about checking that commitment before anyone signs.
Buying channels
How do requesters find what to buy?
Four ways in, each ending in the same requisition record.
Punchout catalogs
- Requester shops on the supplier's site
- Cart returned by cXML punchout
- Lines arrive priced and coded
Free-text requests
- For one-off goods and services
- Buyer adds supplier and price
- Routed to procurement before approval
Classification
- Items coded with UNSPSC or your own categories
- Category drives approvals and GL coding
- Spend reports by category
Purchase flow
How does a purchase move from requisition to receipt?
Each step records who acted, so procurement can answer any question about a PO later.
Requisition
A requester picks catalog or punchout items, or writes a free-text request, and names the cost center or project.
Budget check
The amount is checked against remaining budget, counting open commitments, before the request goes anywhere.
Approval
Rules by amount, category, supplier and budget status route the request to the right approvers.
PO issue
The approved requisition becomes a PO, sent by email, portal, cXML or X12 850, and the commitment is recorded.
Acknowledgment and changes
The supplier confirms or proposes changes. Any change to price, quantity or date goes back through the rules that apply.
Goods receipt
Receivers record full or partial receipts, or confirm services, and the PO stays open until its last line is received.
Budget control
How does the budget check work?
Budget control in purchasing means counting money before it is spent, not after the invoice arrives.
- Budget available is the budget, minus actuals, minus open commitments
- A PO creates a commitment when it is approved, not when the invoice arrives
- Receipts and invoices reduce the commitment as they post
- An overrun can block the request, warn the requester or add an approver, set per budget line
- Project and capital budgets are checked over their whole life, not only the fiscal year
- Commitments are released when a PO is closed or cancelled
Approval rules
Who approves a purchase order, and what is checked first?
An approval rule table of the kind we set up with procurement and finance. The thresholds and roles are yours; the system applies them in order.
| Rule | Who approves | What the system checks first |
|---|---|---|
| Amount threshold | Cost center owner, then the next level of your delegation of authority as the amount rises | The requester is not the approver, and the purchase is not split across requests to stay under a threshold |
| Category: IT | IT or security review before the budget owner | Software and devices against the approved catalog, and any security review already on file |
| Category: capital | Finance and the capital budget owner | The capital project exists and has budget left; asset tagging is flagged for the receipt |
| Budget overrun | Budget owner, plus finance above the overrun level you set | Remaining budget after open commitments, and whether a budget transfer is pending |
| New supplier | Procurement, before any PO is issued | The supplier is approved in the vendor master; if not, onboarding starts first |
| Contract exists | Buyer confirms terms; often no extra approval inside the contract value | The PO references the contract, prices match it and value is left on it |
Rules run in a fixed order and stop at the first failed check, so an approver never sees a request that was going to be blocked anyway.
PO types
Which purchase order types does procurement need?
Different buying patterns need different PO types. Forcing one type onto every purchase is how commitments go wrong.
01
Standard PO
Example: A one-time order for office monitors
Approach: Fixed lines, quantities and prices. It closes when every line is received and invoiced.
02
Blanket PO
Example: Office supplies from one supplier through the year
Approach: A value limit and a validity period. Each release draws it down, and the buyer is warned as the limit or end date nears.
03
Contract PO
Example: A master agreement with set rates for maintenance services
Approach: Terms and prices live on the agreement. Each release PO references it and takes its prices.
04
Service PO
Example: A consultant engaged for a fixed scope
Approach: Received by service confirmation or milestone instead of by counting goods.
After the PO
What goes wrong with change orders and receipts?
Most PO disputes start after the PO is issued.
Challenge
A change order quietly lifts the PO value past an approval limit.
Agnotic approach
Changes run through the approval rules again on the new total, and the version history shows every change.
Challenge
The supplier ships part of the order and the rest never arrives.
Agnotic approach
Open lines stay visible with their due dates, and overdue lines alert the buyer.
Challenge
Receivers post receipts days after the goods arrive.
Agnotic approach
Mobile receiving at the dock with barcode scanning, and reminders for POs past their delivery date.
Challenge
The supplier acknowledges a different price or date.
Agnotic approach
The acknowledgment is compared with the PO line by line, and differences go to the buyer before they become the new terms.
Challenge
Requests are split to stay under an approval threshold.
Agnotic approach
The system flags requests from the same requester to the same supplier that together pass the threshold within a short period.
What do we build into purchase order software?
Modules from the request form to the receiving dock.
Requisition intake
Catalog, punchout and free-text requests in one form, on web and phone.
Punchout and catalogs
cXML punchout set up per supplier, and internal catalogs with contract prices.
Budget and commitments
Budget available by cost center, project and GL account, updated as POs, receipts and invoices post.
Approval engine
Rules by amount, category, supplier and budget status, maintained by procurement without code changes.
PO issue and acknowledgment
POs sent by email, portal, cXML or X12 850, with acknowledgments matched back to the PO.
Change orders and versions
Every PO change versioned, and re-approved where the rules require it.
Goods and service receipt
Full, partial and service receipts, on a phone at the dock or at a desk.
ERP sync
Suppliers, budgets and GL accounts read from the ERP; POs, commitments and receipts written back.
Standards
Which standards does purchase order software use?
cXMLX12 850X12 855 and 860UBL 2.1 OrderingUNSPSC2 CFR Part 200
Facts and sources
Facts behind purchase order software
The order document standards and federal procurement rules behind the approval engine and PO records, each linked to its primary source.
The cXML standard includes documents for catalog content, the PunchOut feature, original, change and delete purchase orders with responses to each, and order confirmation and ship notice documents that cXML.org describes as analogues of the EDI 855 and 856 transactions.
Source: cXML.org (cXML 1.2.071)OASIS UBL 2.1 describes Ordering as the collaboration that creates a contractual obligation between the seller and the buyer, using the Order, Order Response, Order Response Simple, Order Change and Order Cancellation documents.
Source: OASIS Universal Business Language 2.1, section 2.6Recipients of federal awards must maintain and use documented procurement procedures, and keep records sufficient to detail the history of each procurement, including the rationale for the method, contractor selection or rejection and the basis for the contract price.
Source: 2 CFR 200.318(a) and (i) (eCFR)Under the federal Uniform Guidance, a recipient determines and documents its own micro-purchase threshold based on internal controls, an evaluation of risk and its documented procurement procedures, and may award micro-purchases without competitive quotations if it considers the price reasonable.
Source: 2 CFR 200.320(a)(1) (eCFR)
Who it is for
Who do we build purchase order software for?
Organizations where spending is committed by email today and reported on only after the invoice arrives.
Procurement teams in mid-size companies
Buyers moving from email and spreadsheets to one requisition and approval flow.
Multi-site operators
Restaurants, clinics or plants where each site buys locally under central rules.
Grant-funded organizations
Nonprofits, universities and contractors that must document procurement under federal award rules.
Project-based businesses
Construction and engineering firms whose purchase orders commit project budgets.
Scope
What changes the scope of a purchase order build?
We price from these drivers on the scoping call.
Buying channels
Internal catalogs, how many punchout suppliers, and how much free-text buying.
Approval matrix
The number of rules, levels and exceptions in your delegation of authority.
Budget model
Operating, project and capital budgets, and where each lives today.
Supplier channels
Email, portal, cXML and EDI suppliers for PO issue and acknowledgment.
Receiving
Warehouse, site and service receipts, and whether receivers need mobile scanning.
ERP integration
Which ERP holds suppliers, budgets and GL accounts, and what it lets us write back.
Engagement
How does a purchase order software engagement work?
We map one real purchase end to end before we build.
1.
Scoping call
We follow a recent purchase from request to receipt and collect your approval matrix, budget structure and supplier channels.
Scope2.
Requisition to PO for one entity
Catalog and free-text requests, budget checks, approvals and PO issue for one entity, tied to your ERP.
Build3.
Punchout, receipts and more entities
Punchout suppliers, change orders, receiving and further entities, with support after launch.
ScaleFrequently Asked Questions
Procurement software is the broader term and can include sourcing, supplier management and contracts. Purchase order software is the buying part: requisitions, approvals, the PO itself and the receipt. We build the PO flow and connect it to the supplier and contract records you keep elsewhere.
Punchout lets a requester open a supplier's website from inside your purchasing system, fill a cart and bring it back as priced requisition lines. cXML is the protocol many suppliers use for that round trip and for receiving the PO afterwards.
A blanket PO sets a value limit and a validity period with one supplier. Each release draws it down, the system shows what is left, and the buyer is warned before the limit or the end date is reached.
Yes. Thresholds, approvers and categories live in settings that procurement and finance maintain, with every change logged. A developer is needed only for a new kind of rule.
Yes. POs can go out as X12 850 or cXML, with X12 855 or cXML confirmations matched back to the PO. Partner maps and EDI volumes are covered on our supply chain EDI integration page.
The receipt and the PO feed invoice matching. Our invoice processing automation page covers two and three way matching and approval to pay.
It can store the records 2 CFR 200.318 asks for on each PO, such as the procurement method, supplier selection and basis for the price, and apply your documented micro-purchase threshold. Your grants team sets the procedures; the software records that they were followed.