An approved engineering change doesn't automatically stop procurement from buying the old part. Engineering can update a drawing, release the revision, and close the ECO — and an open PO, a supplier quote, or a production plan can still be pointing at the previous revision.
That's how obsolete parts end up on the dock. A buyer places an order for a part engineering has already replaced. A supplier quotes against an older drawing package. A production team receives material and nobody has agreed what to do with it. The real question isn't whether the ECO "reaches ERP." It's whether anyone decided what actually changes, when it takes effect, and who has to act on it.
Consider a purchased bracket with an approved Revision B and an open purchase order for 200 units of Revision A. The supplier may already be making the parts. The new drawing does not tell the buyer whether to cancel the order, accept the delivery, or change the specification. That decision depends on the reason for the change, the supplier's progress, and which production units can still use Revision A.
An ECO is an engineering decision, not a purchase-order decision
An ECO records and controls an approved engineering change. In most companies, that means affected parts, revised drawings, BOM changes, the reason for the change, and the approval context — all tied together. NASA's configuration management guidance describes a useful model: propose, evaluate, approve, implement, and verify.
Procurement, though, has a separate set of calls to make. Once a new revision is out, buyers end up asking things like:
Are any purchase orders still open for the previous revision?
Has a supplier already received an earlier drawing or spec?
Can stock of the older part still be used?
When does the new revision actually take effect — immediately, on a date, at a specific production batch, or only after existing inventory runs out?
Who confirms that the PO, the supplier conversation, and the ERP item record all agree?
An ECO should give procurement the context to answer those. It shouldn't quietly overwrite operational records, and it shouldn't assume every unit of the old part needs to be scrapped.
An approved engineering revision does not automatically resolve existing purchase orders. Procurement must review the applicable revision and effectivity rules before taking action.
What procurement needs from an approved change
Buyers don't need every work-in-progress design iteration. They need a concise, controlled change package once the engineering decision is actually ready for downstream use.
Engineering information
Why procurement needs it
Affected part or item identifier
To locate the item, open orders, supplier records, and stock.
Previous and new revision
To identify which technical definition is being replaced.
Approved lifecycle or release state
To distinguish an approved change from a proposal or draft.
Controlled drawing or specification
To give suppliers and buyers access to the applicable requirements.
Change reason and impact summary
To see whether the change touches form, fit, function, compliance, cost, supplier availability, or lead time.
Effective date or effectivity rule
To decide when the new revision applies to purchasing or production.
Disposition of existing material
To decide whether old stock is used, reworked, returned, or held for review.
An engineering change order documents and controls the engineering change. The operational records — POs, supplier commitments, inventory, production planning — stay with ERP and procurement.
Decide what happens to an open order
The 200-unit bracket order presents four questions that a revision notification cannot answer on its own.
1. Does the change make Revision A unacceptable?
Engineering first identifies the affected part and BOM references, the previous and new released definitions, and the reason for the change. A documentation correction may leave purchasing untouched. A dimensional change could require a supplier to revise its tooling or inspection plan. A safety or compliance correction may mean the old part must not be received or used.
The decision must reference the controlled release, not just a filename or an email saying a new version is available.
2. When must purchasing switch revisions?
Approval does not necessarily mean that every outstanding order must change that day. Engineering and quality might require an immediate hold on Revision A if it presents a safety risk. If Revision B is a manufacturability improvement and Revision A remains acceptable, they might authorize the existing 200 units for a specified batch while requiring Revision B on subsequent orders.
That exception needs a defined boundary: a date, lot, serial range, production batch, or documented use-up quantity. Without one, the buyer and production planner can interpret the same release differently. The Oracle Engineering User's Guide documents effective dates and use-up controls in ECO implementation.
3. What has the supplier already committed to?
Procurement checks the actual state of the order before changing ERP records:
Not yet started: request a revised quotation and confirm whether the supplier can manufacture Revision B instead.
In production: establish how many Revision A units are complete, what can be changed, and the cost or schedule impact of stopping.
Shipped or received: identify the affected lots and obtain an authorized decision to accept, segregate, rework, return, or reject them.
The review also covers purchase requisitions, other open POs, supplier drawing packages, inventory, work orders, and relevant customer or regulatory commitments. Microsoft's engineering change management guidance describes assessing affected transactions and using notifications or transaction controls where appropriate.
4. Who can authorize the outcome?
Engineering approves the technical definition and, with quality where required, whether Revision A remains usable. Procurement negotiates and records the PO action and supplier acknowledgement. Planning identifies the production orders or batches affected by the cut-in. The person responsible for the ECO tracks unresolved exceptions.
For the bracket order, a complete record would identify the approved effectivity rule, the action on the 200-unit PO, the supplier's confirmation, and the disposition of any Revision A material. The engineering release can be complete while those operational actions are still open.
From ECO approval to procurement execution
The handoff is more useful when each stage produces a record someone downstream can act on.
Assess exposure. Procurement and planning identify open orders, supplier commitments, stock, and scheduled production that still refer to the earlier definition.
Authorize the cut-in. Engineering and quality specify the effectivity rule and decide how existing material may be handled. Exceptions have named approvers.
Execute the purchasing changes. Amend, hold, cancel, or explicitly retain each affected PO; issue the applicable controlled documents and obtain supplier acknowledgement. Update the ERP records according to the agreed ownership rules.
Reconcile and close. Confirm that purchasing records, supplier commitments, inventory disposition, and production cut-in agree with the approved decision. Record unresolved exceptions rather than marking them complete.
An integration can transfer released item and revision data into ERP, while an ERP workflow can route reviews and control transactions. Neither automatically decides whether a partly fulfilled order is safe to accept. That remains an engineering and operational decision.
Where the handoff usually breaks
These failures can occur even when the ECO and ERP item master are technically up to date.
The effective revision is unclear. A buyer can see Revision B but cannot tell whether the existing order for Revision A is still permitted. Define effectivity before instructing suppliers. See ECO best practices.
The BOM changes, but existing commitments do not. Updating a future requirement does not amend a purchase order already accepted by a supplier. Review open transactions separately.
The drawing is sent, but receipt is not confirmed. A supplier may continue working to the last acknowledged specification. Keep the acknowledgement with the change record.
The exception is buried in email. An approved use-up decision must remain traceable to the affected lot, order, or batch months later.
Version control in engineering establishes what engineering released; purchasing records establish what a supplier was authorized to deliver.
A change-readiness checklist for procurement
Before the operational side of the ECO is closed, verify that:
The affected item, released revision, and controlled supplier documents are identifiable
The effectivity or use-up rule has an authorized owner and an explicit boundary
Open POs, supplier commitments, stock, and relevant production orders have been checked
Each affected PO has a recorded outcome: amended, held, canceled, or retained under an approved exception
The supplier has acknowledged the applicable specification and order action
Old-stock disposition, production cut-in, and unresolved exceptions are traceable to the ECO
Frequently asked questions
Q: Does an ECO automatically update ERP?
A: Not necessarily. An ECO controls the engineering change. An integration or ERP workflow may create or update operational records, but teams still need rules for field ownership, effectivity, open orders, inventory, and exceptions.
Q: Can procurement keep buying the old revision after an ECO is approved?
A: Sometimes. It depends on the effectivity rule, the reason for the change, supplier commitments, available stock, and whether the previous revision remains approved for a defined use. Engineering and operations should document that decision rather than assuming approval immediately invalidates all older material.
Q: How do ECR, ECO, and ECN differ?
A: An ECR (engineering change request) typically records a proposed change and its initial evaluation. An ECO is the controlled order or record used to review, approve, and implement the change. An ECN usually communicates an approved change to affected teams or external parties. Companies use these terms differently, so define the workflow and responsibilities rather than relying on the label alone.
Q: When should procurement be involved in an engineering change?
A: Bring procurement in when the change can affect purchased parts, suppliers, open orders, costs, inventory, lead times, or manufacturing schedules. The earlier procurement can assess the operational impact, the less likely the team is to discover a conflict after an order has been placed.
Planning a PDM–ERP workflow? Book a demo to discuss how your engineering release and change process should connect with procurement.
I’m Christina Rebel, CEO of CAD ROOMS. For over a decade, I’ve worked at the intersection of cloud engineering collaboration, digital manufacturing, and distributed product development.
Throughout my career, I’ve worked closely with engineers, designers, and manufacturing teams to improve CAD data management, version control, supplier collaboration, and browser-based design review. My focus is on making modern engineering workflows more accessible, secure, and efficient, particularly for SMEs and startups.
I also write about engineering collaboration, with contributed articles published by Design News and DEVELOP3D.
Christina Rebel is CEO of CAD ROOMS and Co-founder of Wikifactory. She has over a decade of experience in cloud engineering collaboration, digital manufacturing, CAD data management, and distributed product development. Her writing on modern engineering workflows has appeared in The Engineer, Design News, and DEVELOP3D.
Learn what makes engineering data AI-ready, from CAD versions and BOM relationships to lifecycle states, ECO history, permissions, and system integration.