If you’re responsible for software-as-a-service (SaaS) buying for your organization, a close relationship with contracts is a must. On the surface, SaaS contracts look like any other contract. But beneath the surface, SaaS agreements have important layers that are essential to understand, especially if you’re the one to sign and manage them.
I’ve spent years buying software and managing more than 1,000 contracts — you could say SaaS contracts and I are on a first-name basis. In this post, I break down the details of a SaaS contract template so the next time you have one to review, you’ll be ready to breeze right through with confidence.
Before we jump into the specifics of a SaaS contract template, there are some common questions I want to answer. Is a SaaS contract the same thing as a SaaS license? And are those the same as a SaaS agreement?
The answers to these questions depend on the SaaS companies you’re working with. Generally, a SaaS agreement is a hybrid of a service and a license agreement. In this post, I use the terms “SaaS contract” and “SaaS agreement” interchangeably. I also use each term to include any license or subscription agreement along with any service level agreement (SLA).
Now let’s jump into the details of a SaaS contract template.
No two SaaS companies will have the same contracts. You can expect contract formats, terms of service, subscriptions, and SLAs to differ. But there are some parts of a SaaS contract that are often standard, and I’ll cover those, step-by-step, here.
But first, here’s an expert tip: There is no part of a SaaS contract that you, as the customer, should think is non-negotiable. In reality, there may be sections of the contract the supplier cannot change for legal reasons, but it does not hurt to ask and require explanation. In most cases, suppliers are eager to find compromise.
A typical SaaS contract includes the following sections:
Let’s take a look at each section individually.
In the introduction of a SaaS contract, you’ll usually find a short statement that indicates which parties are involved in the agreement. As the customer, you will need to fill in sections needing customer input. It might look something like this:
This software as a service (SaaS) agreement is entered into between “Customer” located at “Customer address” and “Supplier” located at “Supplier address” and is effective on “Effective date.” “Supplier” and “Customer” agree that the following conditions of this agreement apply to the services provided under this agreement and supersede all other agreements.
Words can have different meanings to different people, especially across industries. To avoid any misinterpretation, the supplier will include a “Definitions” section to define words commonly used in the agreement, especially headings.
Be cautious here, as it isn’t wise to assume every supplier will define words exactly the same.
What exactly does this agreement grant you? What does the supplier consider acceptable use of the services? That is what the SaaS services section of the contract answers. This section may instead be called “provision of services,” “licensor services,” or "acceptable use policy.”
Example: “During the term of this agreement and subject to the terms of this agreement ‘Customer’ will receive a non-exclusive, non-transferable or assignable right to access and use the subscription for internal business operations.”
Make sure that the scope of the subscription covers everything your company needs to avoid breach of contract.
The supplier wants to be clear about responsible parties and what the expectations are of you, as the customer. The customer responsibilities clause in a SaaS contract describes those expectations. You may see things here like:
When reviewing this section, be sure the responsibilities are things your company can deliver.
A payment clause does not usually address specific pricing but instead expresses how purchase orders, order forms, invoices, and payments will be handled. Some things you can expect to see under this section of a contract are:
Every clause in a SaaS contract is important, but I want to especially emphasize the term and termination clause. Keeping up with contract terms, renewal terms, and termination clauses are some of the most challenging components of contract management — so much so that in our post on SaaS contract best practices, three out of 10 best practices involve how to better manage those things.
Auto-renewal is common in SaaS agreements. You’ll want to note this and request a change to the agreement if your company does not wish to auto-renew. Without a solid SaaS vendor management solution, auto-renewal can result in your company spending a lot of money on “shelfware.”
Term: The initial term of this agreement shall begin on “Effective date” and shall continue until terminated by Customer or Supplier as defined under Termination.
Renewal: This agreement shall auto-renew at the end of each term unless terminated no less than thirty (30) days in advance of the end of the term.
Termination: Customer or Supplier may terminate this agreement, without cause, after giving the other party no less than thirty (30) days of written notice.
When it comes to SaaS, warranties are often slim. This clause usually addresses any performance promises made by the SaaS supplier. For example, the supplier may warrant that it will provide the services promised in the agreement in a manner consistent with industry standards. You might also see statements in this clause relating to supplier-provided data backup.
This contract clause, among several others to follow, is often written in all capital letters so it is conspicuous. In other words, the supplier wants to make sure you see it.
Be sure to include your company security team when you review SaaS contracts, and use a SaaS security checklist to make sure all security needs are met.
A warranty section may read like this:
“SUPPLIER WARRANTS THAT IT WILL PERFORM THE SAAS SERVICES OUTLINED IN THIS AGREEMENT IN A PROFESSIONAL MANNER CONSISTENT WITH GENERAL INDUSTRY STANDARDS …”
“DISCLAIMER: THE SUPPLIER DOES NOT WARRANT THAT ACCESS AND USE OF THE SAAS PRODUCT WILL BE UNINTERRUPTED OR ERROR-FREE.”
As the customer, make sure the warranty protects your company. If the product requires paid implementation and customization, you want to make sure the warranty provides some sort of refund if the system performance is not what was promised.
Though these sections can be in any order, the last few sections of the SaaS contract template address legal matters and how they’ll be handled.
A friendly reminder: Your company legal counsel should be involved in the review of any agreement signed on behalf of the company and can provide valuable legal advice.
An example of something you can expect to see under the limitation of liability clause is:
“NEITHER CUSTOMER NOR SUPPLIER SHALL BE LIABLE FOR INDIRECT, INCIDENTAL, OR CONSEQUENTIAL DAMAGES INCURRED BY CUSTOMER OR SUPPLIER OR ANY THIRD PARTY, REGARDLESS OF THE CLAIM.”
Similarly legal in nature, the indemnity clause defines any indemnification rights on the part of the supplier and the customer. In other words, if a claim is made against either party that relates to the agreement and that asserts that the other party is at fault, the at-fault party agrees to defend the claiming party and cover legal fees.
With the help of your legal counsel or law firm, look for provisions that may not be in the best interest of your company. The agreement already considers your supplier’s protection, so your goal is to ensure the indemnification clause is fair to both parties.
Confidentiality is a big deal in the world of software as a service. Solutions often contain sensitive customer data, but sometimes even the SaaS agreement and associated documents include confidential or proprietary information, intellectual property rights, or trade secrets. This section of the contract defines what confidentiality means to the supplier and then goes on to address how confidential information should be treated.
For example, the supplier may specify that if the customer receives a request for confidential information and the customer is legally obligated to disclose, the customer (the disclosing party) must notify the supplier in advance of any disclosure.
When I worked in technology procurement for a state institution, I had to consider the state’s laws when signing any contract. Because Kentucky was subject to open records laws, I made sure to include a revision stating so in every contract I signed. Your organization may have similar superseding laws that apply to any part of a contract.
Depending on the company, the industry, and the software product, there could be any number of other general provisions in a SaaS agreement. These are some clauses you might see:
Now you’ve made it through what is sometimes called the “terms of service” section of a SaaS agreement. What you’ll typically find after that are the exhibits to the agreement, which are additional documents the supplier intends to include as part of the overall agreement. This will vary but might include things like the pricing schedule and service level agreement.
The price schedule will begin with an introduction, much like you already saw at the beginning of this SaaS contract template. After the introduction, the supplier will provide a breakdown of the subscription term, which may or may not be the same as the agreement term. Next, they’ll provide an itemized list of pricing, or “schedule value,” that defines what the customer is responsible for paying.
Finally, you’ll be asked to complete some customer information so the supplier knows how and where to deliver invoices. In some agreements, the customer information section may be under the payment clause instead.
The SLA is where you’ll find specifications of how support and maintenance will be handled by both the customer and the supplier. An example of this is a table, filled out by the supplier, that includes problem versus response expectations. These are things your company, especially the stakeholder teams, need to know before the agreement is signed.
SaaS system is down or is creating errors that are impacting customer’s business
Supplier support services will respond within one business hour.
Enhancement requests or other noncritical issues
Supplier support services will respond within 48 business hours.
Other common areas addressed in an SLA:
As SaaS buying professionals, we manage large SaaS stacks with a seemingly endless stream of requests from end users for new software applications. Simply put, sometimes we need a little help. Using a SaaS contract template to keep track of key clauses to look for and what they mean is a way to streamline and speed up your processes. It’s also a great way to help protect your company from costly contractual mistakes.
Sign up for an ongoing stream of leading SaaS buying research and resources.
The latest news, technologies, and resources from our team.
At DPW Amsterdam 2022, Vendr talked with Head of Procurement Michelle Vita to cover procurement automation, agility, and ways to empower stakeholders. Check out the highlights.
With the explosion of SaaS, staying ahead of SaaS Procurement and ensuring a lean tech stack has never been more challenging. Procurement professionals work daily to tame the “SaaS vortex” and ensure they maintain value as they add complexity and license volume to the stack. This has forced an evolution in Procurement and new approaches for professionals managing the software buying process.
Michelle Vita is well-versed in this evolution. As a procurement professional with over a decade of building procurement processes for business, Michelle’s career has evolved from traditional procurement roles in private real estate development to high-tech roles in real estate technology and SaaS. Most recently, Michelle took the reins as Head of Procurement for cloud-scale monitoring and security firm Datadog.
At the recent Digital Procurement World conference, Michelle took the time to sit down with Vendr’s KR Barron to talk about taming the SaaS vortex and building a supportive, sustainable procurement practice for Datadog. She shared her insights on team-building, growing an agile organization, and empowering your stakeholders.
We’ve captured the highlights from the session below.
Michelle has spent three and a half years at Datadog evolving the Procurement team from a “department of one” into a thriving, progressive team with operational and strategic mandates.
During that time, she’s come to believe the heart of a progressive, strategic Procurement function is its people.
“There are two types of Procurement personas now,” she explains.
“Classic, traditional procurement professionals, with a 7-step process, etc. Then there’s the new procurement professional. They’re more strategic and agile, more a jack-of-all-trades. The industry, in general, is evolving toward this model.”
These young, powerful professionals and the explosion of SaaS have brought about this new breed of procurement professionals.
These new professionals are also changing the way their stakeholders think about SaaS. They’re empowering employees to negotiate on behalf of their company to buy the right tools, with the perspective of “buying as if you were the owner of the company.”
Michelle describes her own team at Datadog in these terms. Her first hire came by way of an internal candidate who already understood the procurement process from the stakeholder perspective. Michelle described this agile-focused colleague as “one of the best hires I’ve ever had.” This versatility has allowed them to grow with the team, take on new projects, and execute effectively.
Since that first hire, Procurement at Datadog has evolved into a two-pronged department, with members focused on both operations and strategy. The team includes progressive-thinking procurement and contracts experts who leverage technology to educate stakeholders, create good policy, and create a seat at the table for Procurement.
The economic uncertainty of 2022 has ushered in a more measured approach to buying than in previous years. Even as SaaS has become more challenging to optimize, being strategic about your business cases and volume has a positive impact on the software budget.
Where once the rationale was to buy “as many licenses as we can move into someday,” Michelle and Datadog stick to a strategic, “buy as you go” license approach that helps the team save money and be more conservative. Having licenses waiting on the shelf for someday “is money that goes to waste.”
The temptation is to buy the number of licenses you’ll need for a future date, incentivized by the perceived savings of a volume discount. But, “taking advantage of a discount isn’t good if they’re just sitting on a shelf unused,” reminds Michelle.
Instead, the team has become more focused on getting the licenses they need for the current team. Procurement has also focused on the best management of those tools, performing license audits, and ensuring proper utilization. They’ve also gotten more strategic about tier levels. Datadog assigns top-tier licenses for some power users and viewer licenses for others that are cheaper.
When faced with a lack of resources—be it budget, headcount, or data— Procurement is tasked with applying agility to the procurement process. Michelle is always on the lookout for places to reduce human activity.
“I’m a huge supporter of relieving the team of administrative burdens that don’t add value.”
To do this, the Procurement team looks at the end-to-end process, identifies those processes taking up human touch and time, and automates them.
The team has turned once onerous processes into touchless processes that reduce friction in day-to-day operations. For instance, vendor follow-ups used to take up considerable time for the team. Now, those processes are controlled by Robotic Process Automation (RPA). Bots now perform a follow-up workflow for outstanding items, allowing procurement to focus on higher-level tasks.
“Agility is important, but also [means] working with our partners, establishing relationships, and using them to grow.”
The contract process also slowed down internal progress, so the team found ways to reduce friction and remove human intervention from the process. By integrating their contract system with an e-signature tool, they can move contracts for review to Legal automatically, collect signatures, and speed up the contract execution process.
Agility relies on partnerships, so as part of the legal contracts automation, the Procurement team worked with vendors to use internal paper for contracts. Using an internal template that is acceptable to vendors gives the legal team more control over the review process and speeds up the time to completion.
Stakeholder education plays a huge role in creating a collaborative, functional relationship between procurement and the larger organization. The key, says Michelle, is to empower stakeholders with just the information they need to execute.
The Datadog team invested time and resources in ensuring stakeholders had what they needed to learn the ropes. While the company had some resources in place, “Sometimes you need resources for various types of people since everyone learns differently.”
The road to better stakeholder education started with a conversation. “We gathered stakeholder feedback from a survey on our processes.” The team issued an anonymous survey asking users to give their feedback about the purchasing process and the resources available to them.
“Training kept coming up and coming up.”
The team realized that even though resources were out there, the onboarding of those resources could be improved. “Our internal team feedback… kept coming up that people were starting [at the company] and not watching the videos.” Those conversations allowed the Procurement team to identify the issues and develop a plan.
Automation has a part to play in the empowerment process, as well. “We wanted to empower stakeholders to do things that don’t require procurement touch.” To help stakeholders gain confidence in buying on behalf of the company, Michelle and the team implemented a guided help service for users.
Modeled on the “Clippy” office assistant featured in Microsoft Office, the procurement assistant program sits on top of the Procurement system, providing helpful pop-ups for users as they engage with the UI and perform routine tasks. If the user gets stuck or needs assistance, the assistant robot guides them through the process with a “click here” approach. This allows stakeholders to self-service needs without relying on procurement team members directly.
Ideas such as these allow Procurement to remove itself from the areas where it doesn’t add value while still maintaining agility for the wider team. From there, they can develop stronger relationships between departments, gain a strategic seat at the table, and ensure that once they have that position, they can deliver value.
For more tips on driving an enablement, people-first approach in your Procurement practices, take the advice of Sören Petsch, Head of Procurement at CommerceHub.
After all, “If Procurement is the Cost Savings Department, we break the trust of our internal stakeholders all the time.”
A budget variance is an unplanned change between the budgeted spend and actuals. Learn to protect your software budgets from variances with this quick guide.
Your team worked hard to create an accurate budget for the upcoming year. Considerable planning went into the financial model; Finance was confident in its assumptions.
Now it’s mid-year, and your actual figures are off. Potentially really off in some places.
What’s going on here?
Every company — small business and enterprise company alike — deals with budget variances and other FP&A challenges. In a swiftly changing economic and business environment, they’re somewhat inevitable. But you can control their occurrence and impact on the balance sheet.
Today we’ll look at budget variances: How they occur, what to do when you find one, and how to reduce their likelihood and impact on your business.
First, let's fully define what a budget variance is.
A budget variance is a difference between the budgeted amount for a specific department or project versus the actual amount.
Budget variances are a common part of the financial life of most companies. That being said, frequent or extreme variations in the budget can be disruptive to cash flow. Variances may signal a mismatch between expectations and actual results on revenue or planned spending for products and services.
Budget variances can be either positive or negative:
Positive: A positive budget variance (also called a favorable budget variance) means that your company spent less than intended on a specific budget item. There can be several reasons for a positive variance. And while a variance may not be a cause for concern, it pays to research these when they occur. Run a variance report on the business budget to look for any overestimations or changes to liabilities.
A budget variance should always be investigated, even if that variance seems like a windfall.
Negative: Most finance professionals think of this when they hear the word variance. A negative variance (an unfavorable budget variance) refers to spending over the allotted budget. There are several reasons why budget variances occur. While not every variance can be avoided, monitoring can help reduce their occurrence and impact.
Software contracts are also subject to the effects of variance. With a standard subscription built on an annual or monthly basis, variances are less common. Variance in a fixed contract usually happens because a department needs to add more licenses or tools after establishing budgets. But other contract structures — usage-based or drawdowns — are likely causes of unplanned SaaS spend.
Budget variances aren’t always a matter of errors (though sometimes this is true). Here are the five most common sources of budget variances affecting your budgeting accuracy:
Changing economics: Shifting economic conditions is one of the most common sources of changes to actuals versus budgets. Changes in commodities prices, labor costs, overhead expenditures, and services can create big expense variances between the estimated spending and the numbers at the end of the period.
Budgeting errors: Human error does play a factor in budgeting issues. This can be a matter of underestimating actual expenses or even a simple data entry issue on an Excel sheet or a line item. Variances of this type may be positive or negative, but if they occur repeatedly, it may be time to review your budgeting process and streamline where necessary.
Pricing changes: changes to the pricing of your services or fixed assets can create a variance in a budget. For instance, if insurance premiums at renewal are higher than anticipated for a fixed asset costs have risen as a matter of expansion, variances may be the outcome. It’s important to keep an eye on planned expenditures that diverge from the original budget and make adjustments where necessary.
Process streamlining: Improvements in your operational or financial processes may create a positive budget variance. Implementing streamlined spending approval processes, for example, may result in reduced tail spend that will positively impact the budget for that.
Risk and employee fraud: One unfortunate source of budget variance is risk-based costs such as disaster recovery, legal fees, and procurement fraud. These variances are hard to predict and either and harder to avoid. The best prevention for such budget shortfalls is increased due diligence and robust financial monitoring.
Software budgets are subject to variances just like any other cost. Here are some ways your SaaS buying budget may become out of sync with the actuals.:
Changes in how you use a piece of software may result in fluctuating actual costs associated with that tool. For instance, increasing service level tier mid-contract to better route team or project requirements will consume more of the budget than planned. Building flexible budgets with some play for software changes can help alleviate budgeting issues at the end of the period
Usage-based contracts such as those that charge her credit or her impression may result in higher than expected spending for those tools. When establishing a contract for a usage-based tool, discussing scenarios where usage changes is important. Sometimes, the supplier is willing to work with you for anticipated increases mid-contract. A good rule of thumb is that becoming a better customer should never be more expensive.
Draw-down contracts that rely on a pool of funds, service credits, or use may be subject to early renewal if usage exceeds the anticipated amount or allotment. As with overage fees, it’s important to establish the ground rules with your supplier before you sign the contract. Using more of a product should offer an advantage instead of a penalty.
Both overage scenarios above are often associated with underestimating the need for a product at the point of negotiation and contract execution. Building better modeling for expected usage can help reduce the occurrence of this type of variance. Make this a point of negotiation when dealing with a new supplier for a usage-based or drawdown contract.
Sometimes growth requires spending. One source of budget variance is the need for more licenses or seats of a specific software tool throughout the contract. This happens when hiring cadences increase or new projects get underway. This is another point where a successfully negotiated supplier relationship can benefit when you realize your needs have changed.
Budget variance can be an insidious drain on revenue if left unchecked. Overages in your budget, especially those overages which cannot be tied to a product or project, must be mitigated wherever possible.
Budget issues that affect cash flow can affect your financial statements and creditworthiness as a downstream impact if ongoing problems are left unresolved.
Research the variance cause: granular access to data is your best ally in tracking and resolving budget variances. When you discover an issue between your budget in your actuals, take the time to dig into the numbers and establish that the variance has occurred (that it’s not the result of a data entry error or oversight) and the root cause, if any.
Plan a course of action: Once you establish that a budget variance has occurred, you need to decide how you will handle the variance going forward. There are a few possible scenarios for handling discrepancies between your budget and your actuals.
If you find these adjustments are becoming frequent, it pays to investigate and improve budgeting or estimating criteria.
Regular review and maintenance of your budget are the best ways to avoid changes in your actuals outside budget parameters. A streamlined process and help from technology can also improve budget outcomes.
Regular cost performance and budgeting review are essential to reducing or eliminating variances. Some research is a routine part of your financial cadence. For example, large variances may show up during the month and closing activities for flux analysis.
As an added precaution, quarterly budget reviews are a tried and true way of heading off variances in your budget before they can become a more significant issue. Touch base with your department heads to understand changes to the spending plan before they occur and make necessary adjustments as a proactive measure.
For instances where you’re budgeting parameters may change, consider running scenario analysis and creating contingencies for possible outcomes. By building a budget that can absorb a variety of outcomes, you establish more confidence in the budgeting process and smooth the path for later analysis.
If your industry or business is subject to variable costs, seasonality issues, or other changes, consider moving away from a static budget. Rolling budgets, which are adjusted monthly or quarterly, may give your financial reporting the flexibility it needs for more accurate, agile financial planning.
Tracking software usage, especially in usage-based or drawdown SaaS pricing models, can help you avoid overages in your software spending before they get out of hand. Create regular calendar events to check usage numbers or set up notifications within your platform that can alert you to changes between planned and actual usage. The small step will translate to big savings and cost avoidance if your project plans or scope of work changes.
Tracking your spending on SaaS tools is the best way to avoid discrepancies in your budget vs. actual costs. Spend management software centralizes your data, creates metrics for evaluating spending, and allows you to keep track of usage-based contracts before they can spiral out of control. By getting a better grasp on the day-to-day life of your tech stack, you can avoid surprises at the end of the quarter or year.
Get an inside look into the platform where you can discover and buy new tools, see how much you're saving on software, and stay up to date on your IT stack with our free guide to the Vendr SaaS buying platform.
Are you using the correct type of purchase order? It can save time and create a smoother procurement process for buying software. Learn more about them here.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.