A contract is a legally binding agreement that defines and governs the rights and duties between or among its parties. In Coupa, once these contracts have been executed, we have the option of operationalizing them. That is, to use this contract in your procurement process.
If you've negotiated a contract, it's safe to assume you'll want your end users and suppliers to adhere to the pricing, negotiated terms and/or conditions outlined in the contract. When creating an order, by referencing the contract directly on the requisition as a backing document, the supplier will know exactly which agreement you are purchasing against and how to fulfill their obligations as outlined in the contract accordingly. In addition to this, Coupa will default contract information (Supplier, Payment Terms, Shipping Terms, and Savings %) onto the requisition for your users.
Contract-backed ordering is a fundamental savings principle in procurement. It mitigates the risk of rogue-spending, or spending off-contract for goods/services that have been contracted for better pricing.
Customers have a few different options with this functionality, all dependent on your specific procurement policies and the level of insight users in your organization have to procurement contracts.
- Selecting a backing document on a requisition is a feature inherent to users with the buyer role. To expand this functionality to end users, they must be given a role with the permission Approver/Select Contract. If looking to allow this functionality for approvers of the requisition, they will need the Edit Requisition as Approver role in addition to the Approver/Select Contract Permission. Read more about this here.
- Customers have the option to route all requisitions without a contract to a buyer. Furthermore, customers can control the threshold in which these unbacked lines are routed to the buyer. Read more about the Route Requisitions to buyer if no contract is specified company info setting here.
- Just because a contract exists with a supplier doesn't necessarily mean it can be used for purchasing. Contract record configuration settings such as 'used for buying?' and 'stop spend over contract value', along with access restrictions (content groups), can all contribute to a contract not being available for selection on a requisition.
- When associating an item to a contract, the contract will default on the requisition when adding said item to your cart. This is a best practice and something you should consider doing for all items backed by a contract.
- Do your end users have access to contracts directly? Are you also using CLMS/CLMA? If so, set up your contract types to allow end users to submit requisitions directly from the contract instead of on the requisition. Read more about this feature here.
Regional/Country Specific Considerations
Do's & Don'ts
|Design Element||Recommended Design||Alternative Design||Risky Design||Rationale|
|'Route Requisitions to buyer if no contract is specified' setting||Enable the setting to ensure unbacked requisitions are being reviewed by buyers. To speed up cycle times, create thresholds (in alignment with your procurement policy) where unbacked lines below this amount are acceptable.||Create a custom role using the Edit Requisition as approver role and permissions mentioned above to allow approvers to add the backing document as an optional step during their approval. Leverage approval design to ensure purchases without a backing document are added if one exists.||
Do not leverage both 'Route Requisitions to buyer if no contract is specified' setting and 'edit requisition as approver' functionality.
Contract backed ordering is an integral piece of procurement savings, so designs should ensure that orders are not sent to suppliers for goods/services we have a contract for. Enabling this setting allows for this control point, while specifying the threshold on the setting itself will help your organization balance this need while respecting your requisition cycle time goals. Making this requirement the responsibility of the approver is acceptable for organizations that manage contract assignment via specific approvers instead of central buyers (via pending buyer action), but you risk approvers not adding contracts since the step in itself is not gating. Not leveraging either of these options may lead to higher off-contract spending.
|Selecting Contracts on Free-Form Requests||
Apply these select permissions to a custom user role. Apply the custom user role to all users. With that, this functionality is available to all end users.
This design decision assumes that your users understand which contract is relevant to their request.
|Create custom role for free-form contract selection. Apply this role to only specific users that should have this access.||Do not allow end users or approvers to add backing documents to requisitions.||
This design decision goes hand in hand with the 'Route Requisitions to buyer if no contract is specified' setting mentioned above. You can route these requisitions for buyer review if no contract is specified, while also allowing end users to apply the backing document when it is known to them. Not giving this access to the requester or approver may result in bottlenecks and longer requisition cycle times, since every requisition will be routed to the buyer.
Assign contracts to catalog items for the automatic defaulting of the contract and select contract info on your requisition.
Leverage requisition line forms with default supplier/contract values to further drive the correct contract selection on non-catalog requests.
Leverage conditional questions on your requisition line forms to drive the correct contract selection. Use approvers and/or buyers as an additional control point for correct contract selection.
|Do not create contract backed content in Coupa.||
A guided buying experience for your users is an overarching design principle that should be considered in all elements of procurement design. Contract backed ordering is no different. Create your catalog items with a backing document to ensure the correct contract is being referenced on the requisition for catalog orders. You can even deploy requisition line forms to create a guided experience for your user to select the appropriate contract as well. Failing to back content with a contract places the onus on the end user (or buyer/approver, based on designs elements mentioned above). This could result in users selecting the wrong contract relevant to their purchase.
Contract backed Requisition Approvals (CLM Customers)
|CLM customers can facilitate faster approvals for contract-backed requisitions. since the contract record has already gone through approval. Read more about this here.||Leverage existing requisition approvals for contract-backed requisitions.||Since the contract record has already gone through approvals, some customers prefer to shorten the requisition approval. This is dependent on your approval design. Requisition approvals may be distinct from Contract approvals in your organization, where requisition approvals may involve additional or different approvals (Ex Cost Center Owner).|
Heat Map Assessment
|Customer will not be creating requisitions that are backed by a contract.||Customer will be creating requisitions that are backed by a contract.||Customer is still determining use cases for contract backed requisitioning.||There is a risk associated with the customer's usage or non-usage of contract backed requisitioning.||The backing document is being applied to the requisition in an external system before external order transmission.|
Related Success Metrics and Value Drivers
- On-Contract Rate by Order Amount/Count
- Catalog (Punchout and Catalog) Rate by Order Amount/Count
- Suppliers with 80% Spend
- Requisition Approval Cycle Time
- Average Number of Requisition Approvers
- Contract Cycle Time
If these are key metrics for a customer's business, not leveraging contract-backing options available could make a significant impact to these values while not leveraging this feature may be a risk in itself.