We are going through that internally. Legal would like to make it 1:1 but that is unrealistic.
As a general rule, we require a contract for over $50K, or a high importance (nothing can go wrong) or high risk vendors.
In practice, we don't have perfect compliance.
Dollar value and risk are considerations. $25K is our rule of thumb, however, not all POs that are over this amount would be a case for a contract. A PO with listed terms and conditions would usually suffice. If the procured product (or service) is of high risk, however your procurement and legal teams define that, you may need a contract. In addition, if there is a high probability that your terms and conditions and your supplier's T&Cs would conflict, it would be best to hash that out in an agreement prior to committing to a purchase.
Our Legal and Procurement departments definitely would like to see a contract for every purchasing relationships we have, but resources, and expediency get in the way of acheiving that level of perfection. Since we recently migrated to P2P, we had thousands of existing contracts that had to be converted. We started with a data upload to create the contract shells, then the negotiators had to complete the Contract Workspace with the pricing terms, maximums, etc. Eight months later, they are still working on the conversion of the less important and the most complex.
For example, as a worst case scenario, literally more than 100 departments in our company purchase reports from Lexis Nexis. Do you create one contract for each of these departments? If you create one bulk contract for the enterprise, how does the accounting get applied? Do you create one for each line of business? Release or Non-Release? The decision on how you configure the contract will impact both the Requester and the Accounts Payable group during invoicing. Some decisions might still require paper invoices to be submitted to AP with coding unless you have a centralized authority who can review the invoices as they are entered. The best practice is to think about these downstream impacts and do the least amount of harm to each stakeholder. In the end, it might require a process transformation to get all the cogs to turn in the same direction.
Specifically, we have no hard threshold for when to use a contract and when to use a PO. It is mainly determined by the risk associated with the engagement. A purchase of a publication is considered a one-time transaction where a PO will suffice. We do however use some standard terms and conditions when transmitting any PO a vendor. A purchase order for stock photography used by marketing might be generally sufficient, but copyright and fair use restrictions often push us more toward a contract. Donations, charitable giving, sponsorships, and memberships are exempt from contracts so a PO is used. Utilities are paid by Non-PO invoice.
Contracts are required for any vendors who visit any of our locations to perform work. This includes vendors who only electronically access our access our systems, i.e. BPO, and other outsourced agreements. We have contracts for pricing agreements whether the catalog in in the contract or in a punch-out. Multi-year deals should be a contract. Any engagement with regular fixed payments generally requires a contract. Yet, for some smaller engagements like with a coffee service, we have set up a PO instead. Conversely, while we generally will have a master agreement with a vendor of IT hardware or software, we process maintenance renewals as a purchase order, unless it is a multi-year deal.
For a situation when there should be a contract, but there is not enough resources in Procurement to negotiate a contract at the time, we will allow a temporary PO to be created, sometimes for 3 months of payments to bridge the time between when the service is needed and when Procurement will have an open slot to negotiate.