Revised PDF customer orders: avoid entering two versions in your ERP

A customer sends a PDF purchase order, then a corrected version. The first is already in your ERP. The second has a different filename and no clear explanation of what it replaces.

Extracting both documents does not resolve the problem. The workflow must recognize a revision, show its differences and check which changes remain possible. The goal is a decision your sales operations team can act on.

Identify the order before comparing files

Filenames and email arrival order are insufficient. Find the customer's reference, customer account, internal reference where available and ERP order identifier.

A later date does not necessarily mean the whole document replaces its predecessor. The message may contain a correction, supporting evidence or a new order. Ask for confirmation when intent is ambiguous.

Keep versions and their sources. A new attachment must not erase the document used for an earlier decision or shipment.

Compare lines in a common vocabulary

Before flagging a quantity change, establish that the lines refer to the same item and unit. Customer part numbers may differ from your catalogue references. One line may use cases while another uses individual units.

Agree catalogue mappings and permitted conversions with the business team. Similar descriptions do not authorize substitutions. Show candidates for review if several items remain possible.

Separate added, removed and changed lines. Display old and new quantities, prices, units, addresses and requested dates. A changed total alone hides the decision.

A revision may arrive too late for a simple update

Illustrative example: version A requests 20 units. Staff prepare 8. Version B requests 12 in total.

Replacing 20 with 12 without checking operational status is misleading. Those 8 units could be reserved, picked or shipped. Each state allows different actions.

The reviewer checks the ERP and available fulfilment records, then decides what can change, which confirmation is needed and what balance remains. The PDF is a revised request, not a complete account of actual fulfilment.

Define who accepts changes

Receiving a revision and accepting it are separate steps. Specify who can approve modifications, which fields need checks and when another owner must decide.

Prepare a draft update when a change affects an existing commitment. Record the decision owner, accepted version and reason for rejection or partial acceptance.

If the customer must clarify something, prepare the differences for review. Communication and acceptance follow the agreed process.

Use the ERP's supported modification path

Check how your ERP handles external references, revisions, delivered lines and order amendments. Also examine existing CSV imports, portals and EDI options.

The integration must find the existing order and use a supported update mechanism. Creating a new order for every revised PDF turns amendments into duplicates.

After submission, retain the destination identifier and verify the outcome. Recovery after a failure should check whether the amendment was applied before attempting another write.

Test difficult revisions

Include changed quantities, removed lines, unit changes, ambiguous references and revisions received after shipment. Add versions arriving out of sequence and unchanged PDFs sent again.

For each case, agree what should be found, flagged, blocked or confirmed. Measure incorrect associations, missed changes, review time and duplicate creations. Correct extraction does not establish correct acceptance.

Our guide to preparing PDF orders for ERP entry explains intake. Revision control addresses an important exception within that workflow.

Request a Kaliits diagnostic with anonymized versions and your amendment process. We can scope a test around the decision your team actually needs to make.