The problem: a customer order is not yet a usable order.
A customer emails a purchase order with their own part numbers, a delivery address and a note asking for the same terms as last time. Customer service searches old orders to find the equivalent items, converts boxes to individual units, checks contract pricing and asks the warehouse whether the requested date is realistic.
That work is repeated for every line, even on familiar orders. A PDF can be easy to read and still be hard to interpret: a drawing revision may have changed, an address may refer to a different branch, or a quantity of ten may mean ten packs rather than ten pieces. Copying the document into the ERP does not resolve any of those ambiguities.
Errors travel downstream. A wrong unit becomes a short shipment, an old price becomes a dispute, and an assumed delivery date becomes a missed promise. The aim is not simply faster typing. It is a complete, checked order with a clear path for anything the system cannot safely resolve.
Where it shows up
- Customer service copies lines from PDFs into ERP forms.
- Customer part numbers require repeated searches through history.
- Pack sizes, addresses and requested dates need manual clarification.
- Price discrepancies surface only after the order ships.
- Customers ask for status while their order is still in an inbox.
Why it's hard to keep up by hand.
The incoming document and the ERP rarely use exactly the same language. Reliable entry needs both extraction and business validation.
Many ways to name one item
Customers use aliases, legacy codes and free-text descriptions. Similar-looking items can have different dimensions, materials or revisions.
Rules depend on the customer
Contracts, shipping instructions, minimum quantities and credit holds are not generic fields. They change whether an order is ready to release.
A request is not a promise
A requested delivery date needs checking against stock, inbound supply or capacity. Automation must expose uncertainty instead of manufacturing a commitment.
How Faraday fixes it.
Faraday prepares the order with evidence for each mapped line, then asks people to resolve only the details that do not meet your rules.
- Step 1
Collect the customer request
Read the email, PDF or recorded request alongside the customer master, ship-to addresses, product catalog, aliases, price agreements and order history.
- Step 2
Map and validate every line
Resolve customer references to ERP items, normalize quantities and units, compare prices and check required fields. Ambiguous matches remain visible rather than being accepted as guesses.
- Step 3
Check fulfillment constraints
Bring in available inventory, open supply and relevant delivery constraints. Route credit holds, unsupported dates and conflicting instructions to the right team.
- Step 4
Review and create the order
Customer service approves or corrects the draft. Write the approved order to the ERP and preserve the source request and the decisions behind changed lines.
Customer PO · Entry review
Example data · Source-to-order validation
| Customer request | ERP match | Recommendation | Why |
|---|---|---|---|
| ACME-BRG-04 · 10 boxes | BRG-6204 · 100 pieces | Review conversion | Customer alias matches; the approved pack contains 10 pieces. |
| Valve 3/4 in · $18 | VLV-075 · Contract $19 | Resolve price | The requested price differs from the current agreement. |
| Filter · Deliver Friday | FLT-3320 · No stock | Confirm date | The next inbound delivery is after the requested ship date. |
What changes for your team.
| Workflow | Today | With Faraday |
|---|---|---|
| Capture | Copy each field from a document. | Review a draft alongside the source request. |
| Item mapping | Search history for familiar aliases. | See proposed matches and unresolved alternatives. |
| Validation | Catch unit and price issues downstream. | Check units, prices and required fields before release. |
| Exceptions | Keep questions in individual inboxes. | Assign a specific missing detail to an owner. |
| Traceability | Find the original email after a dispute. | Keep the source and approved changes with the order. |
How to measure the impact
Track time from receipt to approved ERP order, manual touches per line, correction rate and unresolved-request age. Review fulfillment errors as well as entry speed so quicker processing does not create more returns or customer disputes.
Common questions about order entry.
What is automated order entry?
Automated order entry converts customer requests into draft sales orders, validates the details against business rules and sends approved records to the ERP. It combines document reading with item mapping, price checks and exception handling rather than just transcribing text.
Can Faraday process emailed and PDF purchase orders?
Yes. The workflow turns emailed and PDF requests into structured drafts for validation. Unclear scans, missing pages or ambiguous instructions should trigger review. For requests taken by phone, the details need to be captured as a record the team can check.
How are customer part numbers matched?
Compare customer aliases and previous order lines with the item master, then check attributes such as size, material and revision. Where several items could fit, ask for confirmation. A similar description is not enough evidence to release a different product.
What happens when the customer price is wrong?
Show the requested price next to the applicable agreement or price record and route the difference for review. Your team decides whether to honor an exception, correct the order or contact the customer. The automation should not silently overwrite either value.
Does order entry automation replace EDI?
Not necessarily. EDI works well for standardized transactions with established trading partners. Document-based automation covers customers who still send emails and PDFs. Both channels need the same validation rules and controls against duplicate orders.
What data does Faraday need?
Customer and ship-to records, the item master, customer aliases, units and pack sizes, pricing agreements, inventory availability, order history and your release rules. Start with a sample of incoming requests and a read-only ERP connection.
Can orders be released without review?
Start with people approving the draft. Later, you may choose to release clean orders within explicit limits, but ambiguous items, credit holds and price conflicts should remain exceptions. Keep a record of the rule and source data used for each release.
