The 4 types of purchase orders you’ll create when buying software

Planning procurement activities — whether for supplies, products, services, or software — requires a high level of visibility. The process gets easier by documenting planned purchases to the best of your ability. Department heads will know what purchases are on the horizon, IT can plan for capacity and implementation, Finance can plan spending more accurately, and accounting can lay the groundwork for a smooth end-to-end purchasing process. 

One way to achieve all these objectives is to streamline the purchase order process. You ensure everyone knows the game plan by documenting purchase information completely (and in advance). 

But what’s the best way to plan if you don’t have all the information? As it turns out, the structure of your purchase order can help show what you know and leave room for future planning. 

Let’s look at the different types of purchase orders you can use for purchasing software, and how to use them most effectively. 

What is a purchase order?

A purchase order form is a standardized form a buyer transmits to a supplier. The purpose of the purchase order is to outline the requirements and necessary information for placing an order and having it filled. Purchase orders are standard practice for businesses buying supplies, goods, and software from their suppliers. The purchase order also serves as a record for tracking and confirming accurate and timely delivery of purchases.

When to create a software purchase order

The purchase order process begins after the evaluation and selection of a supplier. It represents the beginning of the purchase portion of the procurement process, after any needed sourcing activities. 

Most often, a purchase requisition precedes the purchase order. This initial document (sometimes called an intake form) outlines the parameters of the business need, any requirements the solution must meet, and any preliminary evaluation the stakeholder has conducted. The information from the purchase req serves as the basis for completing the final purchase order before transmission. 

The requisition also creates a second data source for checking the accuracy of orders once the products, materials, or software licenses come in. Accounts payable checks the purchase requisition, purchase order, and invoice for parity in a three-way matching process. This process ensures compliance with delivery terms, date of delivery, the quantity of items ordered, etc. It is one component of ensuring legal protection, as it serves as a source of truth for the outcome of a supplier agreement. 

When you know exactly what you need from a selected supplier, you can create a purchase order for immediate or future use. Depending on the timing and quantity of the purchase, you may create one of four common purchase order types: standard PO, planned PO, blanket PO, or contract PO. More on those next. 

The 4 types of software purchase orders and when to use them

While standard POs are most common for the purchasing process, there are several ways to structure a purchase order. The type of PO you use will depend on the details and timeline of your purchase. Selecting the right type of purchase order structure helps smooth the procurement process and aids budgeting and planning from the accounting side. Pre-planning purchases through the right purchase order allows finance to ensure the cash will be available when needed.

Standard purchase orders (SPO)

The Standard PO (aka a “regular purchase order”) is one most buyers are familiar with. Standard purchase orders represent the intent to complete one transaction with a specific product type, quality of items, and quantity. The purchase order should outline all the necessary information for completing the transaction. Standard purchase orders are often used for a one-off purchase. 

For software purchases, a buyer may need a set number of licenses for the company or department. For instance, ten seats of a specific accounting software solution for everyone in the AP department. In this case, they would order the specific number of licenses needed to set everyone up with their own instance of the software. 

Planned purchase orders (PPO)

The second common type of purchase order is that planned orders are similar to standard ones but for a future, undetermined delivery date. These purchase orders are developed with all the details of standard orders. The money for these is placed in a reserve called an encumbrance) so the money will be available when it’s time to place the order. Once it’s time to transmit and fulfill, accounting performs a release of the funds and completes the purchase. 

Planned purchase orders are ideal for purchases that are made on a semi-regular basis. One example is office consumables like coffee and tea. The purchasing department estimates what you’ll need to use based on previous purchases and timeframes. They then create a series of orders and release them as necessary (for instance, when the admin reports they’re down to the last few boxes). Planned purchase orders are handly when the order details are the same, but the exact consumption period isn’t known. 

One example of software purchasing on a planned purchase order: A development team will need 30 licenses of a popular development tracking tool for an upcoming project. The project is slated to kick off in the year's second half,  but the exact date is unknown. In this case, the team can encumber funds within the project budget and create the planned order during the planning phase. When it’s time to implement the tracking software, AP releases the funds and completes the purchase. 

Blanket purchase orders (BPO)

When you know you need an item continually, but you’re unsure of how many, a blanket purchase order can reduce redundant work and make the procurement process smoother. The information stays the same in this case, but the quantity and timeframe are unknown. Printer paper is a great example because its usage fluctuates based on the headcount in the office and the types of projects happening at a given time. With a blanket order, the release happens when the supplies run low, and the quantity is updated based on expected use for the next interval (whether a month, a quarter, etc.) 

Blanket orders may present backorder issues for the supplier if the quantity greatly exceeds expectations. For this reason, blanket orders come with a safeguard for the supplier: they outline a maximum quantity for a single purchase. This ensures the buyer can plan SaaS spending and get what they need (within reason) without creating inventory management issues for a supplier trying to fulfill orders for many customers at a specific period of time. 

In purchasing software, the team may need to requisition communication tools to meet the expected headcount for each hiring sprint. The exact timing of the orders is unknown, and the number of licenses may change depending on the hiring activity. The team can rely on receiving a certain number of licenses even if there is some fluctuation in the headcount. 

Contract purchase orders (CPO)

A contract purchase order has the least detail but still sets up the basic parameters of the purchase for when needed. It's essentially a promise of future orders, and an outline of the terms and conditions each party will adhere to once those POs come to fruition. A contract purchase order is not a binding contract until accepted by the seller.  

Contract purchase orders don’t contain the specific delivery schedule, quantity, or item information. They may have mutually decided timeframes for purchase (for instance, a quarterly estimate). In software, these purchase orders may come in handy when working with a software reseller. They outline the necessary details for transactions but leave the specifics for a future date when more information is available. 

What to include in every SaaS purchase order

Every purchase order — whether standard, planned, blanket, or contract — should offer the baseline details to complete the purchase. When developing a purchase order to buy SaaS software, include the following information for your procurement and supplier-side stakeholders:

Supplier information

Once known, detail the supplier information, including any details necessary to transmit the purchase order and pay the resulting invoice. By outlining the necessary information for the entire purchase process, you reduce back-and-forth communication and ensure quick delivery/implementation and payment of software. 

Tier/service specs

If known, outline the service or tier level information for the products you’re purchasing. By being more specific on the purchase order, it's easier for accounting and receiving stakeholders to verify that the desired products were ordered and delivered. 

Payment details

If the suppler has specific payment terms (for instance, early payment discounts, preferred payment forms, volume order discounts) outline these in the PO to ensure accurate billing and timely payment.

How Vendr can manage your SaaS purchase orders, end-to-end

Using a supplier management system like Vendr can automate many repetitive tasks associated with purchase orders and financial management. By centralizing supplier data, contracts, and license information into one easy-to-use platform, your department stakeholders, Finance, and Accounting departments will maintain a high level of visibility into current software levels, upcoming renewal activity, and future capacity planning. 

To get a handle on your PO process and all your software buying activities, consider creating a stronger intake process with our free template. With a better process, your teams enjoy a smoother procurement experience, more accurate planning, and more data-driven decision-making.