Example project · Connecting your systems - Customer purchase orders into draft sales orders
Order entry re-keys PDF purchase orders into the ERP. We build a path from emailed PO to draft sales order, with anything uncertain landing in a review queue instead of the ERP.
Illustrative project plan. Company details describe the scenario; this page does not claim a completed customer engagement or measured results.
Lakeside Fastener. 60 people, fasteners and industrial hardware, around 120 customer POs a day by email.
The situation
Three order-entry staff type POs into the ERP all day. Duplicate orders and wrong ship-to addresses are the most common complaints from the warehouse.
The ERP has an import path and an API, but nobody has confirmed which operations are licensed or what the integration user is allowed to do.
What we would build
- Week one is spent confirming your ERP product, version, licensing, and the supported way to create a draft order. The design follows what your system supports, not the other way round.
- PO extraction from email attachments, then customer, ship-to, and item matching against your ERP master data.
- Validation rules: duplicate PO number, unknown item, unknown ship-to, credit hold, and price mismatch against the customer’s agreement all go to a review queue.
- Draft sales orders created in a test company first, then in production, clearly marked as created by intake and needing review.
The workflow in action
Before
A customer PO arrives by email. A salesperson enters it into the ERP, updates a spreadsheet, and checks that someone acknowledged it.
A possible implementation
The approved intake record becomes a validated ERP draft through a supported API or controlled import.
- The original request and processing status remain traceable.
- Held records land in a visible queue with a named owner.
- A daily digest shows what was created, held, or failed.
The less glamorous parts matter.
- Validate
- Check the customer, ship-to, item identity, unit, currency, and required fields against approved records.
- Prevent duplicates
- Define a transaction key, duplicate detection, and safe retry behavior before allowing writes.
- Handle failures
- Route missing records and failed transactions to a visible queue with a named owner. Don’t silently drop the order.
- Reconcile
- Record the result and check that approved inputs match the intended output. Preserve an audit trail.
What you would see - Week by week, what lands on your desk.
Week 1
A feasibility note naming the ERP integration path, the permissions required, and any licensing question to settle before building.
Weeks 2 to 3
Extraction and matching run against 300 historical POs, with your order-entry lead reviewing the results on screen.
Week 4
The review queue live, and draft orders appearing in the ERP test company for three chosen customers.
Weeks 5 to 6
Production go-live for those three customers, a daily digest of what was created, held, or failed, then expansion to the next group.
What you would have at the end
- The intake and integration service, documented, with error handling and a named owner.
- A review queue for held orders and a daily digest email.
- A written description of every validation rule and what happens when each one fails.
What it would not do
- Confirming or releasing orders. Drafts stay drafts until a person acts.
- Overriding credit holds, pricing, or inventory allocation.
- A promise to integrate with any ERP. The path is confirmed before anything is built.
How we would measure it
- Share of POs reaching the ERP as drafts without manual entry.
- Duplicate and wrong-address orders per month.
- Order-entry hours per day, before and after.
Let’s start with one thing.
What would better performance look like?
Bring a result you want to improve, a symptom, or a workflow you already understand. You do not need to know the bottleneck yet. We’ll help choose what to investigate first.
No transaction files needed for the first conversation.