Sales Order Exception Handling Before ERP Entry
An order that cannot go into the ERP without a decision must never be lost, half-entered or silently corrected. Handle it with a fixed list of exception types and a rule for each, hold only the lines that need a decision where your process allows it, set thresholds you can defend, show the reviewer the exact place in the source document, and log who decided what. This guide gives the taxonomy, a worked order with accepted and held lines, the review screen, the audit log and three indicators to run it by.
- Published
- Sources checked
- Reading time
- 9 min
- Written by
- Mirage Metrics team
Scope: B2B orders received by email, PDF, spreadsheet or scanned form, in manufacturing and industrial distribution, before entry into any ERP. It covers the decisions around entry, not how to set up automatic order entry, which the related articles cover.
Decision snapshot
- Best suited to
- Order desk and customer service managers, operations leads and ERP owners at manufacturers and distributors who receive orders in many formats.
- Inputs needed
- The inbound mailbox, the customer master with delivery addresses, the item master with units and conversions, customer cross-references, price lists and contracts, stock availability, and each customer's order rules.
- What can be automated
- Reading orders in any format, classifying what is not an order, matching customers and items, converting units with defined conversions, checking quantities, prices and availability against rules, detecting duplicates, entering clean lines, routing exceptions with their evidence.
- What requires human approval
- Choosing between candidate items, confirming inferred units and outlier quantities, accepting price differences, adding a delivery address, creating a customer, and changing the rules.
- When this approach is insufficient
- When master data is unreliable (duplicate customers, missing conversions, stale prices): exceptions then measure data quality, and fixing the data comes first. Also when most orders are negotiated case by case rather than placed against agreed terms.
The exception taxonomy, with a rule for each
A closed list of exception types is what makes handling consistent between people and measurable over time. Each type has a detection signal, a rule, an owner, and an answer to one question: can the rest of the order proceed?
| Exception | How it shows up | Rule | Who decides | Rest of the order proceeds? |
|---|---|---|---|---|
| Unknown customer | Sender or bill-to not found in the customer master, or matches several | Match on exact identifiers first (account number, VAT or tax ID), then on address; never create a customer automatically | Order desk; credit control for a new account | No: the whole order waits |
| Ambiguous product | Description or customer reference maps to more than one SKU, or to none | Use the customer's own item cross-reference first; if still ambiguous, propose candidates, never pick one | Order desk | Yes, if your process allows split entry |
| Unit of measure | Quantity with no unit, or a unit the item is not sold in | Convert only with the item's defined conversions; infer a unit only when the price on the order points to exactly one, and flag the inference | Order desk | Yes, flagged |
| Quantity | Far outside the customer's history for that item, or not a multiple of the pack size | Compare with the customer's own history and pack rules; hold outliers above a factor you set | Order desk, with sales if large | Yes, if your process allows split entry |
| Price | Price on the order differs from the price list or contract beyond a tolerance | Never enter the customer's price silently; hold for a sales decision | Sales or pricing | Depends on your policy |
| Availability | Item not available on the requested date | Apply the customer's rule: partial shipment, backorder or substitution, as agreed with that customer | Order desk, with supply planning | Yes: enter and notify |
| Address | Ship-to not among the customer's registered delivery addresses | Hold; confirm with the customer through a known contact before adding an address | Order desk; credit control if the risk policy says so | No: affects every line |
| Duplicate | Same purchase order number, or the same lines, already received | Compare PO number, customer, lines and dates; a resend is linked, not entered | Automatic, with a log entry | No: nothing entered |
| Not an order | Delivery confirmation, stock query, quote request, the company's own purchase order | Classify and route to the right queue, with a log entry | Automatic, reviewable | Nothing to enter |
Units of measure
Customers write units their own way ("CS", "carton", "x6", no unit at all). Map each customer's spelling to the item's units in the ERP through defined conversions, kept per customer. The item master decides what a unit means for your product, not the customer's document.
Line holds and order holds
Some exceptions concern one line; others concern the whole order. Treat them differently:
- Order-level: unknown customer, unregistered delivery address, duplicate. Nothing is entered until they are resolved, because every line depends on them.
- Line-level: ambiguous item, unit, quantity, price, availability. If your customers and ERP process allow it, enter the clean lines and hold the rest, and tell the customer which lines are pending.
- Per-customer switch: some customers want one delivery per order. Record that preference in the customer's rules, so the split never surprises them.
Worked example: one order, six lines
Illustrative example, invented figures: a PDF order from a food distributor's customer
Assumptions, all invented. The customer is known and the ship-to is one of its registered addresses. This customer accepts split entry, with backordered lines shipped when complete. Price tolerance is 2 percent. Prices are in euros.
| Line | On the order | Proposed | Reason | Status |
|---|---|---|---|---|
| 1 | Butter 82% block 10 kg, x 12 | BT-8210, 12 cases | Exact customer cross-reference, price matches | Entered |
| 2 | UHT whole milk 1 L, 66 | MK-1001, 66 cartons (inferred) | No unit on the order. Order price 1.05 matches the carton price (1.05), not the case of 6 (6.10). Unit inferred and flagged | Entered, confirm unit |
| 3 | Cream 35% 5 L, x 8 | CR-3505B (bag) or CR-3505P (5 x 1 L pack)? | Two items match the description; the customer has bought both | Held: choose item |
| 4 | Emmental block, 400 | EM-2000, 400 kg? | Customer's last 20 orders for this item: 30 to 50 kg. Ten times the usual quantity | Held: confirm quantity |
| 5 | Goat cheese log 1 kg, x 20 at 3.20 | GC-1010, 20 units | Order price 3.20, contract price 3.45, outside the tolerance | Held: sales decision |
| 6 | Plain yogurt 125 g, x 24 packs | YG-0125, 24 packs | Available two days after the requested date; customer rule: ship when complete | Entered, date notified |
Three lines go into the ERP, two of them with a flag the reviewer confirms after entry. Three are held, each with a single, specific question. Twelve minutes later the customer resends the same PDF: same PO number, same lines. It is recognised as a duplicate, linked to the first order in the log, and nothing is entered twice.
Confidence levels and thresholds
Extraction tools produce confidence scores. A score is only useful once you have checked it against your own orders; until then, define confidence by rules you can explain to an auditor. A simple scheme per field:
| Field | Use as is when | Send to review when |
|---|---|---|
| Customer | Exact match on account number or tax ID | Anything else |
| Item | Exact match through the customer's cross-reference | Description match only, or several candidates |
| Unit | Stated on the order and valid for the item | Missing, or inferred from price |
| Quantity | Within the customer's history band for the item | Outside the band you set |
| Price | Within tolerance of the price list or contract | Outside tolerance |
| Requested date | Parsed unambiguously (for example, an ISO date or a spelled month) | Ambiguous formats such as 03/04 |
Make the thresholds configurable per field and per customer, and change them one at a time, with the pilot data in front of you. A customer with a clean, stable format can earn looser rules; a new customer starts strict.
The review screen
The reviewer's screen decides whether exceptions are resolved in seconds or in minutes. It should show, for each held line:
- The source document open at the page, with the region the value came from highlighted
- The value read, the value proposed, and the master data candidates side by side
- The exception type and the rule that raised it, in plain words
- The customer's history for that item: last quantities, units and prices
- One-click actions: accept, choose a candidate, correct, reject, escalate, with a mandatory reason for corrections
- What happens next: entered now, or sent back to the customer with a question
Evidence from the source document
Every value in the ERP should be traceable to where it came from. Keep the original email and attachments unchanged, record a hash of each file, and for each extracted value store the page and region. When a customer disputes a delivery three weeks later, the answer is one click away, not a search through the mailbox.
Human validation and the audit log
| Field | Content |
|---|---|
| Order and line | Internal ID, customer PO number, line number |
| Source | Email ID, attachment name, page and region the value came from, file hash |
| Exception | Type from the fixed list, the rule that raised it, the values compared |
| Proposal | What the system proposed, with its confidence class |
| Decision | Accepted, corrected (old and new value), rejected, escalated |
| Who and when | User, timestamp, time from exception to decision |
| ERP result | Order number created, or the error returned by the ERP |
Review the log weekly, grouped by exception type and by customer. A correction made often is a rule to change or a cross-reference to add, not a reason for more reviewers.
Never lose an order silently
The worst failure is not a wrong line; it is an order nobody knows was received. Build the process so that it is impossible:
- Every inbound email and attachment receives an ID when it arrives.
- Each ID must reach a terminal status: entered, held with a reason, not an order (with its class), or rejected with a reason.
- A daily count reconciles inbox to statuses. The balance must be zero.
- Anything without a terminal status after a delay you set alerts a named person.
- A line that cannot be read never fails the whole order and never disappears: it becomes an exception with a diagnosis.
- Processed emails are tagged in the mailbox, so the team can see at a glance what the system has handled.
A parallel pilot
- Choose a set of customers that represents your formats, including the difficult ones.
- Let the team enter orders as usual. The system processes the same orders on the side and writes nothing to the ERP.
- Each day, compare the system's result with what the team entered, line by line, and classify every difference: system error, team error, or genuine ambiguity.
- Tune rules and cross-references from those differences, and re-measure.
- Move to live entry for clean lines only when the errors-after-validation figure for automatic lines meets the threshold you set, and keep review on everything else.
Three indicators, defined
Define the indicators before the pilot, and publish the definitions with the numbers. A rate without its definition cannot be compared with anything.
| Indicator | Definition | Note |
|---|---|---|
| Orders without intervention | Orders entered with no human action on any line, divided by all real orders received in the period | Count orders, not lines; exclude items classified as not an order |
| Errors after validation | Lines corrected after ERP entry (amendments, credit notes or returns caused by entry), divided by lines entered; report separately for lines entered automatically and lines a person validated | The number that shows whether automation or review is the weak point |
| Time to resolution | Time from exception raised to decision, as a median and a 90th percentile, by exception type | The median hides the orders that wait a day |
Questions to ask a vendor
| Question | A good answer |
|---|---|
| Which exception types do you detect, and can we add our own rules? | A fixed list you can see and change, not a single confidence score |
| Can clean lines be entered while others are held? | Line-level handling, switchable per customer |
| What exactly makes an order go through with no review? | Documented conditions per field, that you can tighten |
| How does a reviewer see the source of each value? | The document opened at the right page and region |
| What happens to a document that fails to parse? | It lands in a queue with a reason; it never disappears |
| How do you prove no order was lost? | A daily count from inbox to ERP, with every item accounted for |
| What is logged, where, for how long, and can we export it? | A decision log you own |
| How do you handle a change in our price list or catalogue? | Master data synchronised from the ERP, not copied once |
| What figures can you show from a real deployment, and how were they measured? | Named deployment, date, definitions; not a generic automation rate |
Where Mirage fits
Mirage built the email-to-ERP order pipeline at Biodéal, a distributor of organic dairy products whose customers order by email in their own formats, with orders created in SAP Business One. The case study describes the exception handling this guide recommends: anything that is not an order is rejected, units are inferred from the price and flagged for confirmation, a line that cannot be read goes out as an alert with a diagnosis instead of failing the order, and processed emails are tagged. Its published figures, which describe that deployment only: 2,943 orders processed automatically since launch on July 22, 2025, a median of 48 seconds from email to order ready, 113 customers, about 7 percent of orders flagged for a human check, 12,993 order lines entered automatically, and zero lines lost silently, by design.
Questions readers ask
What is an order exception?
Any order, or order line, that cannot be entered into the ERP without a human decision because a value is missing, ambiguous or conflicts with master data: an unknown customer, an item that matches two products, a quantity with no unit, a price outside tolerance, an unavailable item, a new delivery address, or a duplicate.
Should the clean lines of an order be entered while others are held?
Often yes, because holding a whole order for one ambiguous line delays everything else. It depends on your customers and your ERP process: some customers want one delivery, some ERPs make amendments costly. Make it a rule per customer, and never split when the exception concerns the customer, the address or a duplicate, which affect every line.
What confidence threshold should we use for automatic entry?
A model's confidence score is not a probability of being right until you have measured it on your own orders. Start with conditions that do not depend on a score, such as exact matches against master data, send everything else to review, and loosen the rules one field at a time as a parallel pilot shows where they are safe.
How do we make sure no order gets lost?
Count every inbound email and attachment, and give each one a terminal status: entered, held with a reason, classified as not an order, or rejected with a reason. Reconcile the count daily. Anything without a status after a delay you set raises an alert to a named person.
What share of orders can be processed without a person?
It depends on your customers' formats, your master data and your rules, so any general figure is marketing. Measure it on your own orders in a parallel pilot. For reference, the one Mirage deployment with published figures, Biodéal, reports that about 7 percent of orders are flagged for a human check; that describes that distributor, not a benchmark.
Sources and scope
Checked on . Scope: order handling before ERP entry. The method, tables and example are Mirage's own, with invented figures; the Biodéal figures are quoted from its case study.
- Mirage Metrics, Biodéal case study: every Biodéal figure and mechanism quoted on this page
Related on this site
- Manufacturing: order intake and ERP workflows
- Biodéal case study: email orders into SAP Business One, with exceptions handled
- Sales order entry automation: the workflow this guide sits in front of
- SAP sales order automation: the same orders, created in SAP without custom ABAP
- How to automate ERP order entry for distributors: setting up automatic entry
- Reduce ERP order entry errors: 5 root causes: where entry errors come from
Run your own orders through the rules
Send us a week of real orders, including the awkward ones. We will return each order with its lines entered, held or classified, the reason for every exception and the evidence behind it, so you can compare it with what your team did.
Prefer to talk it through? Book a call