Quote-to-order revision control

An industrial quote rarely becomes an order in one step. The OEM issues Rev 0. The buyer asks for an alternate motor and split delivery. Engineering updates the configuration. Sourcing replaces an expired supplier quote. Commercial management approves a lower margin. The buyer sends a purchase order against “your latest proposal” and attaches a specification that sales has not seen before.

If the company stores only the final PDF, it loses the chain behind the promise. If it stores every file without relationships, nobody can tell which one governed. Order entry copies price and quantity into ERP while engineering starts from a different drawing set. Both records look current inside their own systems.

Revision control fixes the handoff by treating each issued quote as a named commercial baseline. The baseline binds scope, product definition, assumptions, cost, price, schedule, terms and source evidence. A later request creates a new candidate state. It does not silently overwrite the state the customer received.

Define the object that receives a revision

Decide what the quote revision controls. For a simple product, one document number may suffice. For an engineered system, the revision should point to a package: proposal, line structure, configuration, technical exceptions, drawings, commercial terms, cost basis, delivery plan and supporting supplier quotes.

Do not force every source document to share the quote revision. A customer specification may remain Rev C while the OEM issues proposal Rev 4. Record the revision of each source inside the proposal baseline. The relationship matters: proposal Rev 4 used customer specification Rev C and OEM arrangement drawing Rev B.

ISO 10007 applies configuration management across the product and service life cycle. ISO describes planning, identification, control, status accounting and audit as core configuration activities. A quote baseline needs the same controls at the commercial boundary.

Separate a working draft from an issued quote

People need to edit the quote without creating a customer revision for every saved change. Use a working draft while sales, engineering, sourcing and finance prepare the response. Create an issued revision only when the authorized sender releases a defined package to the customer.

Lock the issued package. A correction or customer request starts another draft based on that package. The new draft can change until release, but the earlier issue remains intact. This gives the team freedom to work and gives the company a reliable record of what the buyer saw.

Give each issued package a complete manifest

A manifest lists every file and structured record in the issue. Include document number, revision, title, date, source and checksum or immutable file reference. Record the quote line structure and configuration directly alongside the attachments. The team should be able to reconstruct the offer even if a linked source later changes.

Capture the sender, recipients, release time and channel. If a portal creates its own submission ID, store it. If the customer asks for a replacement after submission, preserve both portal events and mark which issue the OEM considers active.

Carry customer sources by revision

List the customer RFQ, specifications, drawings, data sheets, addenda and clarification answers that govern the offer. When a new source arrives, compare its identity and revision with the active set. Do not replace the file until someone decides whether it changes the offer.

ASME Y14.35 establishes methods to identify and record revisions in engineering product definition and related documents. Apply that discipline when customer documents enter the quote. The estimator needs to know that supplier RFQs used drawing Rev B while the final offer uses Rev C.

Version the offered configuration with the quote

The quote should point to one offered configuration. Record selected options, quantities, interfaces, approved substitutions and engineered exceptions. If the product configuration changes, create a new configuration version and decide whether the customer-facing quote also needs a revision.

Do not edit a released configuration in place. Engineering may need the old state to explain the price, process a later order or support a unit already sold. The configuration version should lead to the BOM, drawings, software and documents that support the offered state.

This does not mean every internal calculation belongs in the customer package. It means the company can move from the issued commercial line to the exact technical state that made the line feasible.

Version the cost and price separately

Cost and price can change for different reasons. A supplier update may raise cost while commercial management holds price. A negotiated discount may lower price while cost remains fixed. Give each estimate and approval its own version, then record which ones support the issued quote.

Do not recalculate historical margin using current costs and call it the original decision. Preserve the cost, rate, exchange and supplier basis approved at issue. Later analysis can compare the historical estimate with current outlook, but the two answer different questions.

Write a revision note that names the change

“Updated proposal” is not a revision note. List the changed scope, configuration, quantity, price, date, term and source. Also state what remains unchanged when that point could be disputed. A reader should understand the commercial effect without comparing two hundred pages.

Use the detailed comparison behind the note. The customer-facing summary may contain five changes while the internal diff records 42 changed fields and documents. Both should point to the same revision pair.

Compare revisions at field and document level

Run a structured comparison when a draft starts and again before issue. Compare line items, configuration, quantities, prices, discounts, delivery dates, milestones, terms, assumptions, exceptions and document manifests. Show additions, deletions and changed values.

Document comparison alone will miss a structured price or configuration change. Field comparison alone will miss a revised specification attached under the same title. The workflow needs both. SAP’s document history comparison illustrates the value: each saved order version remains available and users can compare versions to identify what changed.

Route only the affected decisions

A revision should reopen the approvals its changes invalidate. A new motor may need engineering, cost and delivery approval. A discount may need only commercial approval. A changed limitation of liability needs contracts review. Repeating every approval on every revision slows the quote and trains people to approve without reading.

Record the basis for reuse. “No impact” should come from a comparison rule or an accountable owner, not an assumption by the workflow. If an underlying supplier quote or cost rate expires, reopen the dependent cost and margin approval even when the customer scope stays the same.

Control alternate and optional offers

Alternates need stable identities. Name the base offer, each option and the rules for combining them. Record whether an option adds to, replaces or excludes another line. If the customer accepts an option, the order baseline should show the resolved configuration and price, not a pile of quote pages that require interpretation.

Price and delivery may depend on a bundle. State the dependency. An optional spare drive may use the project discount only with the main equipment. A faster delivery option may replace the standard date and add premium freight. The acceptance record should resolve those conditions explicitly.

Capture acceptance against an exact issue

The customer’s PO, email or portal award should identify the accepted quote and revision. If it does not, ask for confirmation or document the company’s proposed interpretation. Do not assume “latest quote” means the same package in both organizations.

Record partial acceptance and exceptions. The customer may accept base equipment, reject one option and condition the order on a different delivery date. Those choices create the candidate order baseline. They do not make the quote PDF itself the executable order.

Reconcile the PO instead of converting the quote blindly

Compare the accepted quote revision with the customer PO at header, line, schedule, document and term level. Classify every difference as match, accepted selection, administrative mapping or exception. Resolve material exceptions before creating an executable order.

The PO-versus-quote comparison should produce the evidence for this step. Revision control supplies both sides: the immutable quote issue and the identified customer-order issue. Without those baselines, the comparison can only inspect two files that may already be stale.

Create an order baseline that can stand alone

The order baseline should state the final supply without asking execution teams to interpret negotiation history. Resolve selected options, quantities, configuration, governing documents, price, delivery, payment, exceptions and customer responsibilities. Link the accepted quote and PO as evidence.

Give the baseline an effective date and approval. Then use it for engineering handoff, sales-order creation, project setup, procurement and production release. Negotiation history remains accessible, but it does not compete with the accepted state.

Create the ERP order by reference

Where the ERP supports it, create the sales order with a reference to the accepted quotation. Preserve the external PO ID and quote revision in structured fields. Map each final order line back to its quote line, option or approved exception.

SAP’s sales-order interface includes a reference sales document for a preceding quotation and an immutable external document ID. Its change timestamp supports controlled updates. Oracle Order Management creates a numbered revision when users revise a submitted order and retains the earlier versions. These features help, but the implementation must still carry the right accepted package into the transaction.

Do not mark the quote converted simply because an order number exists. Confirm that price, configuration, schedule, terms and references match the approved order baseline. A successful API call proves transport, not commercial correctness.

Do not let a proposed change alter live demand

After order creation, a customer may ask for another revision. Record the proposed state separately while engineering and operations assess feasibility. The released order remains the execution baseline until approval. Otherwise a tentative customer request can change MRP, supply or work orders before the company accepts it.

SAP documents this exact need in sales-order version management: users can store a proposed version without immediately affecting material requirements planning, then consult production before acceptance. The principle matters across systems. Proposed, approved and effective are distinct states.

When the change receives approval, create the order revision and propagate it through the commercial change-control process. Record which work uses the old baseline and where the new one becomes effective.

Use status accounting to answer what is current

A revision register should answer which customer request, quote, configuration, cost estimate, PO and sales-order versions exist; which one is current; which ones the customer received or accepted; and where approved changes have reached execution.

ISO defines configuration status accounting as formal recording and reporting of configuration information, proposed-change status and approved-change implementation status. This is the missing bridge in many quote processes. The sales team knows the latest proposal, PLM knows the released product and ERP knows the active order, but nobody can prove their relationship.

Audit the chain before release

Before engineering or production release, sample the chain from customer requirement to quote line, accepted configuration, order line and released product record. Check document revisions and approvals. Confirm that superseded sources cannot appear as active attachments in the execution package.

Use exceptions to focus review. A missing link, changed file under the same revision, expired supplier basis, manual order line or unresolved PO difference should stop the affected release. Do not make the audit a ceremonial checklist after work begins.

Worked example: a $7.2 million water-treatment skid package

An OEM quotes three water-treatment skids. Rev 0 uses customer process specification Rev 3, configuration C11 and delivery in one lot. The customer asks for duplex filters, a different PLC brand and split delivery. Rev 1 updates configuration to C12, adds $214,000 and separates the first skid from the remaining two.

During clarification, the customer removes one standby pump but adds a five-year warranty. The OEM issues Rev 2 at $7.2 million. Its manifest contains the compliance matrix, layout Rev D, process diagram Rev F, configuration C13, price schedule, warranty qualification and delivery plan. Commercial approval PA-209 supports the margin exception.

The customer PO says “per latest quotation” but references layout Rev C and adds customer specification Rev 4. The workflow does not convert it. It compares PO-8841 with quote Rev 2, identifies the stale layout and new specification, and asks the buyer to confirm. Engineering finds that specification Rev 4 adds a cybersecurity test but does not change hardware.

The parties sign an order clarification that adopts quote Rev 2, layout Rev D and the new test for $18,000. The order baseline resolves three skids, configuration C13, the selected PLC, split delivery, five-year warranty and the cybersecurity test. ERP sales order 61042 links to quote Rev 2, PO-8841 and approved exception OE-14.

Two months later, the customer proposes moving the second shipment forward. The team creates candidate order Rev 2 without touching live demand. Planning prices the recovery, the customer declines and the candidate closes. Production continues on order Rev 1. The history proves that no accepted schedule change occurred.

Measure late differences and broken lineage

Measure how often the order contains a requirement, date, term or configuration absent from the accepted quote. Count how long the team takes to reconcile the PO, how many order lines need manual reconstruction and how many downstream records start from the wrong revision.

Track revision volume by cause. Many revisions from customer clarification may reflect the market. Many revisions from internal cost expiry, configuration errors or approval rework point to process defects. The number alone means little without the reason and the point where the change entered.

How Bourne controls quote-to-order revisions

Bourne assembles each quote issue from the approved scope, configuration, cost, price, schedule, terms and source documents. It creates the manifest, records the release event and locks the issued package. A customer request or new source creates a successor draft with a structured comparison to the active issue.

When the PO arrives, Bourne compares it with the accepted quote revision and builds the candidate order baseline. It routes differences to engineering, commercial, finance or contracts, then creates the approved sales order and handoff records in the systems that own them.

Later changes follow the same chain. The proposed revision remains separate from released demand. After approval, Bourne writes the new state to CRM, ERP, PLM and project records and tracks its effectivity through closure.

Test revision control with one completed order

Choose an order that passed through at least three quote revisions, one customer addendum and a PO exception. Reconstruct every issued package. Identify the exact configuration, cost approval, supplier basis and source revisions behind each one. Then rebuild the accepted order baseline.

The test passes when the team can reproduce what the customer received, explain every revision, compare the PO with the accepted issue and trace each executable order line back to an accepted source. Add a proposed post-order change and prove that it cannot alter live demand before approval.

Any missing link becomes implementation work: a field to structure, a source to preserve, an approval dependency to encode or a target-system reference to write. Do that work before automating issue and conversion at scale.

Buğra Gündüz

Buğra Gündüz is the co-founder and CEO of Bourne and co-founder of HockeyStack. He built HockeyStack into an eight-figure AI business. At Bourne, he works with entrepreneurs and established companies to create AI products and services.