What it means
A customer sends an updated purchase order with a later delivery date, but the internal sales order still reflects the old date, and this measure checks whether the accepted customer revision and internal order stay aligned. Define the controlling customer PO revision and the seller acceptance, since a new document received by email is a proposal until the commercial process accepts its changes.
Oracle describes sales-order revisions with version numbers after submission, which shows how internal history can be kept but does not validate a customer PO by itself. Compare customer legal entity, PO number, revision, item, quantity, price, ship-to, delivery date and special terms, because a matching PO number can conceal line changes, and check the origin and authenticity of the revised document so a forwarded attachment from an unknown address does not silently change a major order.
If only one line changes, preserve the unaffected lines and their fulfilment status, since a header-level overwrite can shift the whole order. For goods already shipped, distinguish remaining open quantity from completed deliveries, because a revised PO cannot retroactively alter what was dispatched.
If the customer reduces quantity after production begins, route cancellation and work-in-process costs under the agreement, as matching data is not the same as accepting the reduction, and when price changes, check approved quote or contract authority because a purchase order can contain a price the seller never offered. For customer-specific specifications, verify the drawing revision and affected production lots, since a clerical match may still conceal a technical mismatch.
If a new delivery date conflicts with capacity, obtain an achievable promise before confirmation, check ship-to and bill-to separately, and for blanket orders identify whether the revision applies to one release or the full programme. Keep each customer version, receipt timestamp, comparison and accepted outcome, because replacing the original file makes later disagreements hard to resolve, and if two revisions arrive close together, confirm which is latest and whether it supersedes all earlier changes.
Where an integration imports POs automatically, verify exception queues and failed messages, as a successful import status may not reflect line-level acceptance. If a revision is rejected or partly accepted, send the appropriate commercial response rather than treating the internal order as aligned.
Define a checkpoint such as sales-order confirmation, production release or shipment, define the denominator as accepted customer PO revisions or affected lines in the period, and classify mismatches by version, product, quantity, price, timing, destination and terms. Audit selected cases from the original customer document through accepted revision, internal version and fulfilment, and report open high-impact mismatches and orders already in production beside the rate.
The purpose is an order everyone can execute under agreed terms, not a fast reflex to mirror every customer document regardless of feasibility.
In practice
Real-world examples.
Example
The customer revises a delivery date, sales accepts it, and the matching order line is updated before confirmation. The internal version number increases and the earlier date is kept in the history. The warehouse sees only the accepted date.
Example
The customer cuts 100 units to 80 after 60 ship. The seller records the effect on the 40 open units rather than rewriting shipped history. The open quantity falls to 20 and the commercial team reviews any cancellation cost.
Example
An updated PO names a different drawing revision. Sales routes technical review before accepting the change into production. Production waits for the engineering answer rather than building to the old drawing.
Formula
Calculation
Accuracy = accepted revised PO lines correctly reflected in current sales orders / accepted revised PO lines checked at the gate x 100.
Worked example: at the production-release gate, 50 accepted revised PO lines are checked and 44 are correctly reflected in the current sales orders, so accuracy is 44 / 50 = 0.88, or 88%. The six mismatches are 3 delivery dates, 2 quantities and 1 price. The price mismatch is examined first, because it affects revenue on an order already scheduled for production.Case study
Seen in the real world.
This fictional case follows Valecrest Components. A customer sent a revised PO changing one item date, but an interface updated every line on the internal order. The sales team caught the change before production scheduling and restored the unaffected dates.
The case is invented. Valecrest then compared the interface log with a sample of revised POs each week. In one month, 44 of 50 checked lines matched, 88%, and the six mismatches led to a corrected mapping rule so that line-level changes stayed at line level.
Watch out
Common mistakes.
- Treating every inbound PO revision as automatically accepted.
- Applying one line change to the whole order.
- Editing the current order without preserving earlier shipped quantities and versions.
Questions
People also ask.
Does a customer PO always override a signed contract?
No. Conflicts need review under the agreement and authorised acceptance process.
Can part of a revision be accepted?
It may be, with a clear customer and seller record of the accepted scope.
What about already shipped lines?
Preserve their history and apply accepted changes only to the appropriate open scope.
From the founder's library
Take it further with the book.
Build your financial confidence beyond this definition. Shihan's full-length guide, Accounting Fundamentals, takes the same plain-English approach and turns it into a complete, practical playbook for non-finance managers, business owners and students - with chapter-end quiz answers and presentation slides included.
25% off with code MMHQ25, applied at checkout. Priced in USD - checkout may show the equivalent in your local currency.
View the book and save 25%Related