Purchase requisition software that prices the request before it's sent.

Purchase requisition software gives every internal purchase request the same shape and the same path. In Bollard, a requisition records what is needed, how many, by when, against which budget code and why. It then shows the person raising it the estimated cost and the approval route.

That matters most in organisations that buy across many sites. When requests arrive by email, phone and chat, procurement spends its time chasing missing details: which campus, what size, which budget. A structured requisition asks for those details once, at the start, from the person who knows them.

A purchase request needs enough detail for someone else to approve and order it without going back to the requester. That means the item, the quantity, the date it is needed, the site, a budget or cost code and the reason for buying.

Bollard fills in what it can. Item descriptions and costs come from the item master, so the requester never types a price and the estimate uses the same figures purchasing works from. The budget code and reason are required fields, so an approver never sees a request without them.

Requisitions keep spending within policy by stopping the wrong request before it is made. Each site sees only its approved items, every request needs a budget code and a reason, and the cost is visible up front. A requester who can see the total and the approvers can judge whether the request is reasonable before an approver has to.

Rules can go further where a sector needs them. In the higher-education configuration, grant and cost-centre codes are checked before a request is sent. For civil construction, every request is coded to a project and a cost code. For regional healthcare, item lists are limited by clinical role.

A purchase requisition is an internal request to buy, and a purchase order is the document sent to a supplier once that request is approved. The requisition asks for permission. The PO commits the organisation to a price, terms and a delivery site, and the supplier works from it.

Keeping the two apart is a basic control. The person who needs the goods describes the need, someone with authority approves the spend, and purchasing chooses the supplier. In Bollard the approved requisition moves on to sourcing, so the order is raised from what was approved and nobody re-types it.

Requisitions are the first of seven steps: request, approve, source, order, receive, match and pay. What the requester enters here sets the terms for everything after it.

The step before is the item master. Its costs produce the estimate and its site lists decide what can be asked for. Safock imports your catalog and vendors during setup, in days 4 to 7 of the first two weeks.

The step after is approval. The route the requester saw before submitting is the route the request takes, chosen by amount, site and role. Once approved, the request goes to sourcing and the purchase order with its budget code and reason attached.

A shared request sheet is live today but has no controls, and a typical ERP has controls after months of implementation. A requisition system configured to your process gives you the controls in about two weeks.

With a spreadsheet, approval happens by email and memory, prices are re-typed at each step, and sharing the file shares every site's requests with everyone who opens it. Anyone can overwrite a cell.

A typical ERP requisition screen uses the vendor's vocabulary, and its approval routing arrives after a long configuration project. Bollard uses your words for sites, roles and documents, so a head chef raises a Kitchen order and a site foreman raises a Site material requisition. Routing is set up during discovery.