When staff compare a supplier statement with a request, the useful first result is often a list of missing items and quantity or price differences, rather than two long tables to scan repeatedly. The archived request asks for those differences and a path from reviewed values into purchasing. I did not interpret that as permission to make the documents agree automatically. Preserving the request and received contents separately is what makes a meaningful review possible.
A comparison is not an instruction to rewrite the source
Order quantities and prices describe what was requested. The received statement supplies values that need examination. Replacing either side when they differ destroys the basis for comparison. The preserved implementation separates expected lines from reviewed actual values and distinguishes a read-only preview from a write. Looking at a comparison should not itself change the order or create an actual purchase record.
Eliminating a difference is not always the correct outcome. A partial statement may legitimately contain less than the full ordered quantity. A price adjustment may require an explanation rather than copying the original price over it. Explicit scope and reasons let the system retain a reviewed difference. The product goal is an understandable decision, not a screen containing as many green matching indicators as possible.
Retain what the person actually reviewed
A checked complete flag alone does not explain which values were examined. The archived code associates the comparison with source and order state, reviewed rows and confirmation. Where automatically read text is used, row provenance and review status also matter. Recognizing characters and accepting their meaning as business values are different operations. Keeping that difference makes later correction possible without guessing what a previous person saw.
If linked source or order information changes after approval, the old approval should not silently cover the new basis. The preserved implementation checks whether the review basis is stale and requires a new review. I see that as protection against an enduring completed badge for a changed target. Showing the changed information and reason for rechecking is also a product requirement: staff should understand the pause rather than encounter an unexplained extra approval step.
A purchase draft is not payment or final confirmation
Preparing a purchase from the comparison requires current reviewed information. When a source covers several sites, relevant lines can be grouped into the appropriate site drafts. Those are new internal records for review, not alterations to the supplier original or the earlier purchasing request. Confirming the draft and recording actual payment remain distinct tasks. The interface should describe the record being prepared instead of implying that the whole settlement process is finished.
Repeated preparation also needs deliberate behavior. The archived implementation checks request identifiers and contents and recognizes a purchase already prepared from a review. Losing a response should not lead staff to create a second purchase under a fresh request without checking the first result. The contract includes what a repeat returns, not just the message produced by a successful first click. That boundary matters when several screens or an AI connection can request the same operation.
An owner needs a path from the difference to the work
A large difference count tells an owner that something needs attention but may not explain the decision. It helps to connect a difference to its site, supplier, original, partial-delivery scope and review state. A reviewed difference should not remain indistinguishable from an unresolved error, while an unexamined value should not appear normal merely because it has a number. The overview needs to preserve the meaning of the underlying work.
Review synthetic cases for missing products, partial quantities, changed prices, mismatched overall totals and an order edited after confirmation of the comparison. Distinguish explained differences from conditions that must block progress. This article examines selected comparison code and dated inspection records; I did not retest the operating data or actual supplier originals. The useful automation is a precise handover of reviewed values into the next task, rather than an attempt to hide uncertainty and finish several different business events in one action.