Importing a purchase order is not a transcription task. A document can be read perfectly and still create the wrong sales order because the customer account, delivery site, product, unit, or commercial terms were matched incorrectly.
A reliable import therefore has two jobs. It must capture what the buyer sent, then test those values against the records and rules used by the seller. The checklist below follows that sequence and shows which problems should stop an order before it reaches the ERP.
1. Establish the order identity
Start with the fields that identify the order as a business transaction: the customer, purchase-order number, order date, requested delivery date, currency, and destination. These values determine which records and commercial rules apply to everything that follows.
Treat the customer name printed on the page as evidence, not as a database key. Trading names, abbreviations, billing entities, and group companies can look similar while pointing to different accounts. Match against a known customer record and keep the source text available for review.
| Field | What to verify | Stop the import when |
|---|---|---|
| Customer | One active customer record matches the buyer | No record or several plausible records match |
| PO number | The value is present and unique for that customer | The same customer and PO number already exist |
| Dates | Order and requested dates are readable and plausible | A required date is missing or cannot be read |
| Currency | The document states one currency consistent with the order | Lines and totals use conflicting currencies |
| Destination | The ship-to text resolves to an allowed customer location | The address is unknown or ambiguous |
2. Resolve the buyer and delivery site separately
The account that places the order is not always the location that receives it. One customer may buy centrally and ship to several branches, warehouses, or job sites. Matching only the buyer can send otherwise correct goods to the wrong address.
Compare the delivery name, street, postal code, city, and any customer location code with the ship-to records attached to the customer. If the document contains a new destination, route it for review rather than creating a permanent location from unverified text.
3. Match every line to one sellable item
A customer may order with its own part number, a shortened manufacturer code, or a description copied from an old quotation. The import needs to connect that evidence to one internal SKU without losing the buyer's original reference.
Use exact customer-part mappings first. Then consider manufacturer codes, normalized descriptions, and account-specific history as supporting evidence. When several products remain plausible, show candidates to the reviewer. Do not turn a similarity score into an automatic product choice.
- Preserve the source line number and customer part number.
- Resolve the line to one active internal SKU.
- Check that the item can be sold to the matched customer.
- Keep the source description beside the selected catalog description.
- Block approval when the match is missing or ambiguous.
4. Validate units, quantities, prices, and currency
These fields are connected but should not be collapsed into one generic line check. A unit mismatch changes what the quantity means. A price mismatch changes the commercial agreement. A currency mismatch can make every numeric comparison meaningless.
Compare the ordered unit with the catalog or customer agreement before checking the price. Ten boxes at €24 per box is not the same order as ten pieces at €24 each, even when the numbers on the page were extracted correctly.
| Check | Question | Reviewer decision |
|---|---|---|
| Unit | Does the ordered unit match the sellable or contracted unit? | Select the correct unit or confirm an allowed conversion |
| Quantity | Is the quantity valid for that unit and pack size? | Correct the quantity or record the accepted exception |
| Unit price | Does the PO price match the applicable customer price? | Use the contract price, accept the PO price with a reason, or hold the order |
| Currency | Is the line priced in the order currency? | Correct the currency before comparing values |
| Line total | Does quantity multiplied by unit price equal the stated line total? | Correct the source value or resolve the calculation difference |
5. Recalculate the order totals
Do not accept a printed subtotal or final total simply because it is clearly visible. Recalculate line totals from the reviewed quantity and unit price, then compare their sum with the document subtotal and final amount.
Differences can come from rounding, freight, discounts, tax, or a genuine error. The import should identify the difference and expose the contributing values. It should not silently force the lines to equal the stated total.
- Recalculate each line from the reviewed values.
- Sum reviewed lines independently of the printed subtotal.
- Account for stated freight, discount, tax, or surcharge lines.
- Use a documented rounding rule and currency precision.
- Require a decision when the recalculated and stated totals still differ.
6. Separate reading uncertainty from a business-rule failure
A blurred quantity and a clear but unknown SKU require different work. In the first case, the reviewer checks the source document. In the second, the text is known and the reviewer must resolve it against the catalog.
Keeping these categories separate makes the review queue useful. It tells the operator whether to inspect the page, choose a record, or make a commercial decision. A single warning badge does none of those jobs well.
| Exception | What is known | Next action |
|---|---|---|
| Reading uncertainty | The source value may have been read incorrectly | Compare the field with the document |
| Record mismatch | The source value is readable but has no unique match | Choose or create the correct controlled record |
| Commercial difference | The order and seller records disagree | Correct or accept the difference with a reason |
| Order conflict | The problem affects the complete order | Resolve the conflict before approval |
7. Check for duplicate purchase orders before ERP entry
The strongest duplicate check uses the matched customer and purchase-order number together. A PO number can legitimately repeat across different customers, but it should not normally create two active sales orders for the same account.
Run the duplicate check again after a reviewer changes the customer or PO number. The original check is no longer valid when either part of the identity changes.
8. Approve the saved order, then prepare the handoff
Approval should apply to a saved version of the order, not to unsaved fields still sitting in a browser. Run the deterministic checks again when the reviewed version is saved. Only that version should be eligible for approval and ERP handoff.
Keep the source document, reviewed values, exception decisions, approver, and timestamps together. If the ERP import fails or a customer disputes the order later, the team needs to reconstruct what was received and why the final values were used.
- Save the corrected customer, destination, header, and line data.
- Run matching, commercial, total, and duplicate checks again.
- Require reasons for accepted commercial differences.
- Record the person and exact order version approved.
- Prepare only the approved version for the client's ERP process.
A good import leaves fewer unanswered questions
The point of a purchase-order import is not to eliminate review. It is to remove repetitive retyping while making the remaining decisions explicit. When the identity, delivery site, product matches, commercial values, totals, duplicates, and approval are settled in one path, the ERP receives an order the team can explain.
Use the checklist on a representative batch of customer orders before changing the live process. Record which checks fail, how often reviewers override them, and which customer records need cleanup. That evidence defines the integration work better than a generic connector list.