AI Adoption GuideProcurementOrder
Contract terms auto-applied to PO
AI extracts applicable pricing tiers, discounts, and Incoterms from the contract and maps them to PO fields at creation.
Procurement processRequestApproveSourceEvaluateSelectOrderReceiveReview
By Don, DoneThat’s AI coach · updated
Stamp the PO from the signed agreement, not from memory
The quality job at order is to copy four commercial fields from the executed contract that covers this buy: unit price, volume tier, Incoterm, and payment terms. Copy them for this vendor legal entity, this item or price-book family, and this buying entity. If the signed file is silent on a field, leave that PO field blank. Do not invent a discount tier because other suppliers in the category have one, or because last year's PO had one.
Requester memory is not a source. Neither is the last purchase order, the punchout list price, or "what we usually get." Those are how negotiated terms disappear between signature and transmission.
This is not contract drafting. Contract term pre-population belongs at select, when you still have a shell. After signature, the agreement is the source document. The PO is an order against it. Warehouse and AP will treat stamped fields as agreed. Three-way match automation will then match the invoice to whatever you issued, including a PO that never reflected the contract.
Pull price, tier, Incoterm, and payment terms at create
Run this at PO create, whether a buyer keys the order or PO auto-generation from requisition builds it from an approved request. Do not wait until the vendor asks why the price is wrong.
Resolve the governing agreement first:
- Vendor as named on the signed file, not the vendor group or parent brand in the ERP.
- Buying legal entity (company code, plant company), not the requester's cost center.
- Item, or the price-book family the schedule actually uses.
- PO date inside the agreement's effective window, including the latest amendment that covers this SKU.
Amendments and side letters count only if they sit in the same repository as the base file. A PDF in a buyer's inbox is not in force for the stamp.
From that file, pull only what the clause supports:
- Unit price. Currency, unit of measure, and price unit (per kg, per 1,000, per hour). A catalog price is a suggestion until it matches this schedule.
- Volume tier. The band this order falls into under the contract's own basis: contract year or calendar year, this SKU or the family, this order alone or cumulative receipts. You need the running total against that basis, not quantity on this PO only.
- Incoterm. The named term and the named place if the clause has one. FCA Houston warehouse is not a bare "FCA."
- Payment terms. Net days, and any early-pay discount only if the signed file writes it.
Show the buyer the source on the PO screen: contract ID, clause heading, excerpt, effective dates, amendment number. The buyer confirms or sends it back. Confirmation is a recorded action. Auto-send is not.
If lookup fails, or confidence is low because the schedule is a scanned table, leave the field blank and queue it. Blank is honest. A filled guess is a fake term.
Executed agreements usually live in a CLM repository. Ironclad and Icertis are in that class. Purchase orders are created in a buying system. SAP Ariba and Coupa are in that class. Treat them as the two sides of the join, not as a ranked list.
Last year's price, the parent MSA, and the PO that is not a contract
Three failure modes show up as soon as the stamp looks finished.
Last year's price. The ERP info record, punchout catalog, or last PO still holds the prior schedule. An amendment effective in March is already in the CLM file. The buyer copies February. Stamp from the current executed file with an effective date, not from PO history. Volume year is the same trap: if the contract year starts 1 April, a January cumulative against calendar year-to-date can drop the order into the wrong band.
The parent MSA on a local affiliate. Global Inc. signed an MSA with FOB origin and Net 60. The plant that needs the goods is a local company that either signed a local supply agreement or signed nothing. Stamping the parent MSA onto that PO applies terms the local entity never executed, often in the wrong currency, with an Incoterm that does not describe the actual route. Match the legal entities on the signature blocks, not the vendor name the requester typed.
The PO treated as the executed contract. Once the fields look complete, people edit the PO to "change the deal," or skip legal because the order already "has the contract." A purchase order is not the agreement. Changing DAP to EXW on the PO does not rewrite the MSA. If the contract is silent on a volume discount, leaving the discount blank is the correct stamp. Filling a category-typical percentage invents a term the supplier did not sign. The supplier can still invoice the contract price. You have taught AP that the PO is the truth.
Illustrative example: one film SKU, two entities, three prices
The following is a made-up but realistic order, not a case study and not reported results.
A packaging buyer has an approved requisition: 8,000 kg of film SKU FILM-200 for the Düsseldorf plant, need-by in three weeks. The requester entered "Northshore," copied last quarter's US unit price, and left Incoterms and payment terms as the form defaults.
A naive stamp, trained on US PO history, would write: vendor Northshore Polymers, unit price $2.40/kg, volume tier "5,000+ kg, 8% off," Incoterm FOB Houston, payment Net 60. It looks like contract compliance.
What the signed files actually contain:
- US OpCo and Northshore Polymers USA Inc. Supply agreement for the contract year starting 1 April. Schedule A prices FILM-200 at $2.18/kg in the 5,000-19,999 kg band, Incoterm FCA Houston warehouse, payment Net 45. US receipts of FILM-200 in the current contract year already sit in that band. This requisition is not a US buy.
- DE GmbH and Northshore Polymers GmbH. Local supply agreement. FILM-200 is €1.95/kg. There is no volume schedule. Incoterm DAP plant gate Düsseldorf. Payment Net 30. No film volume discount appears in the file.
The correct stamp for this PO is the local agreement only: vendor Northshore Polymers GmbH, buying entity DE GmbH, unit price €1.95/kg, volume tier blank because the contract is silent, Incoterm DAP plant gate Düsseldorf, payment Net 30. Show clause 4.1 (price) and clause 7.2 (delivery and payment) on the screen. The buyer confirms.
If the system had applied the parent MSA, the German plant would have issued a USD FOB order the local warehouse cannot receive as written. AP would later see an invoice at €1.95 DAP against that PO. PO anomaly detection might catch the overwrite if someone "fixes" the PO to match the invoice. Three-way match would either flood exceptions or, after the "fix," look clean against the wrong commercial deal.
Confirm the clause before the order goes out
Ship this as a create-time stamp in the buying system you already use, with the executed file as the source. SAP Ariba and Coupa are where many teams already issue POs. Ironclad and Icertis are where many teams already store the signed agreement. The mapped fields are a proposal until the buyer confirms the clause.
Before you turn it on for a category, replay a sample of issued POs against the current executed files. Score unit price, volume tier, Incoterm, and payment terms separately. A fluent wrong Incoterm is a fail. Unit price may prefill when the schedule row is unique. Volume tier and discount should start blank unless the running total and the basis are both known. Name who owns exceptions: buyer for confirm, category manager when the SKU is not on the schedule, legal when entity match fails, AP only after the PO is issued.
Do not stamp an expired agreement. Send those to contract renewal alerting and leave commercial fields blank until there is a live file. After confirm, anomaly detection is the second line if someone edits price or Incoterms before transmit. Three-way match will bless whatever you stamped.
If buyers stop opening the clause because the fields look finished, you have a tidy PO and a quality miss. The test is whether silence stays blank and whether the discount on the PO exists in the signed file.
Is this worth automating for you?
Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other.
DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.
Measure the baseline first