# Customer PO processing: a correct total can hide a 12x quantity error Source: https://www.digiparser.com/blog/customer-purchase-order-processing [See all posts](/blog) Last updated on September 28, 2026 # Customer PO processing: a correct total can hide a 12x quantity error Manufacturing Customer purchase orders [![Pankaj Patidar](https://avatars.githubusercontent.com/u/17493609?v=4) Pankaj Patidar @thepantales ](https://x.com/thepantales) ![Customer PO processing: a correct total can hide a 12x quantity error](https://www.digiparser.com/images/blog/customer-purchase-order-processing-cover.webp) Automate incoming customer POs by extracting the fields, checking the commercial meaning, and testing the handoff to your order tracker or sales-order system. **Start with quantity, unit and item identity together. A matching line total is not enough.** In the example below, a $1,200 line still totals $1,200 after a mapping mistake reduces the ordered quantity from 120 units to 10. This guide is for the **manufacturer selling goods and receiving a customer's PO**. Your customer is the buyer. This is separate from your procurement team issuing supplier POs or your AP team processing supplier invoices. ## The $1,200 order that loses 110 units Consider a fictional order for mounting brackets. The customer orders **10 cases at $120 per case**. Your approved item reference says one case contains 12 individual brackets, and your destination records quantities in eaches. Record Quantity Unit price Line total Customer PO 10 cases $120/case $1,200 Correct destination line 120 each $10/each $1,200 Incorrect destination line 10 each $120/each $1,200 All three totals match. The incorrect line still passes a check that multiplies destination quantity by price and compares the result with the PO amount. But it represents only 10 brackets instead of 120: **one-twelfth of the intended quantity, or 110 units short**. This is our constructed counterexample, not a measured customer error. Its method is simple: multiply case quantity by units per case, divide case price by the same factor, and preserve the extended amount. With a pack factor of 12, the quantity and unit price must change together. **A correct total proves arithmetic consistency. It does not prove that the order contains the right goods or quantities.** ![Three $1,200 lines: 10 cases correctly becomes 120 each, while an incorrect 10-each line retains the same total.](/research/customer-po-handoff/pack-size-check.svg) ## Preserve what the customer actually sent Extract the source fields before applying internal lookups. Keep the customer item code, quantity, unit, unit price, currency, requested date and line number. Preserve the original document reference so the order-entry owner can compare the result with the PO. A useful header includes the customer name, customer PO number, revision if supplied, ship-to address and requested delivery date. A repeating line-item table contains one row per order line. Do not replace an absent value with a plausible guess. Keep identifiers as text. `00123` and `123` can be different product codes. Microsoft documents that Excel can remove leading zeros during automatic number conversion and recommends setting the relevant import columns to text. Apply the type before data is converted; display formatting cannot recover an identifier whose original value has been lost. [Microsoft: keeping leading zeros and large numbers](https://support.microsoft.com/en-gb/excel/keeping-leading-zeros-and-large-numbers). ## Use an approved item reference, not a similar description The customer's part number may differ from your internal item number. Resolve it in the context of that customer and the relevant unit or variant. A description such as "mounting bracket" is not enough to choose between sizes, finishes or packaging options. Microsoft Business Central supports item references that connect customer or vendor terminology with internal items, including units and variants. That is a concrete example of why this information belongs in a maintained mapping, rather than an assumption made from the PDF text. [Microsoft: use item references](https://learn.microsoft.com/en-gb/dynamics365/business-central/inventory-how-use-item-cross-refs). For our fictional case, the approved relationship is: Source meaning Approved destination meaning Customer C-100, customer item BRACKET-A Internal item BR-01 CASE 12 EA 10 CASE 120 EA USD 120 per CASE USD 10 per EA A different customer can use the same external code for a different item. A case can also contain a different number of units for another product. **Never apply one pack conversion to every line just because the word "case" appears.** If the reference is absent or has several valid matches, hold the line for a person to resolve. ## Six cases to test before the first live import Use these cases with a copy of your tracker, a test company or another approved test destination. They test the handoff after extraction; they are not an OCR benchmark or a DigiParser performance test. Case What the test changes Expected decision 1\. Direct eaches 24 EA at $12.50, with one approved item match Accept the $300 line 2\. Case conversion 10 CASE at $120, with 12 EA per case Accept 120 EA at $10 3\. Total-only trap Same source as case 2, but candidate output is 10 EA at $120 Reject the candidate; the $1,200 total hides the wrong quantity 4\. Leading zero Source item 00123 becomes 123 Hold for review; preserve the source identifier 5\. Ambiguous item Two approved records match the supplied reference Hold for review; do not choose the first result 6\. Repeat submission The same approved order is submitted again after a successful write Return the existing record; do not create another order [Download the six synthetic test cases as JSON](/research/customer-po-handoff/test-cases.json) and [download the independent check script](/research/customer-po-handoff/check_cases.py). Run `python3 check_cases.py test-cases.json` to reproduce the six expected decisions. The script checks these fixtures only. It does not connect to DigiParser, Excel or an ERP. For the repeat test, our fixture assumes the same customer ID, PO number and revision identify an already processed order. Agree the actual rule for your business. A revised PO, a scheduled release and a repeated email need different handling. Keep the destination record ID and the result of the earlier write so an uncertain retry can be resolved. ## Put the checks into a small pilot Start with representative incoming orders, including different customer layouts, multi-page tables, pack units and missing references. Compare the extracted rows with the source, then test the actual destination output. A correct preview is only one checkpoint. 1. Define the source fields and the destination columns. 2. Confirm customer and item lookups, unit conversions and date meanings. 3. Review extracted values and resolve missing or ambiguous information. 4. Import into the test destination and read back its rows or record ID. 5. Repeat one successful submission and test one changed order. 6. Measure corrections, missing or duplicated lines, destination failures and time to a usable result. A spreadsheet can be the final destination. An internal application can also be the right next step. If you need a sales order in an ERP, test the configured import or connection, permissions and receiving-system rules before enabling live writes. At a 23-person manufacturer, the person entering orders and the owner may cover the whole pilot. In a 201-500-person firm, the order-entry owner may need a systems colleague and a spending approver. Confirm those responsibilities rather than assigning them from job titles alone. ## Where DigiParser fits [DigiParser's customer PO parser](/solutions/purchase-order-parser) extracts header fields and line items for review and structured output. Your configured receiving process supplies customer/item mappings, pack conversions, duplicate controls and the final record write. The [integration directory](/integrations) helps you assess a destination route; support for one route does not establish a tested connection to every ERP. Some teams use the same order data to track production or delivery status instead. Keep that useful outcome in scope, while defining document matching and partial-delivery rules separately. Email attachments are one intake example, not a requirement for every customer. ## What should we check if the total already matches? Check the customer, internal item, quantity, unit, unit-price basis, currency and requested dates. Then check line count and whether the order was already processed. The total is one check within that set. ## Should we convert all quantities to eaches? Use the unit your receiving process requires. If it accepts cases and preserves the correct meaning, conversion may be unnecessary. If it requires eaches, use the approved item-specific pack factor and convert quantity and price together. ## What is a successful first milestone? A reviewed order that reaches the intended destination with the right item, quantity and unit, and can be retried without an unintended duplicate. **Test the meaning of the line, not just its total.** [Try the six-case check with your customer PO workflow](/solutions/purchase-order-parser), explore [manufacturing document workflows](/solutions/for-manufacturing), or use the separate [supplier invoice guide](/blog/vendor-invoice-processing) for your AP team. * * * [See all posts](/blog) Automate recurring documents next: [supplier invoice parser](/solutions/invoice-parser), [customer purchase order parser](/solutions/purchase-order-parser), and [extract data from PDF](/solutions/extract-data-from-pdf) hub. ## Transform Your Document Processing Start automating your document workflows with DigiParser's AI-powered solution. [Start Free Trial](https://app.digiparser.com/auth/join)[Schedule Demo](/contact)