Epicor Eclipse Order Entry Automation for Eclipse ERP Sales Orders from Customer PO PDFs

How customer orders reach Epicor Eclipse today

Epicor Eclipse is the ERP that a large share of US electrical, plumbing, HVAC and PVF distributors run their branches on. Its Sales Order Entry screen is built for a counter or inside sales rep who knows the customer, the job and the catalog, and for a phone order it is quick. The slow part of the day is the other pile: purchase orders that contractors, facilities teams and OEM buyers email as PDF attachments. Each one is read on one monitor and typed into Eclipse on the other, line by line.

There are four ways an order gets into Eclipse without that typing, and it helps to be honest about what each one covers.

Epicor describes the Eclipse API as a .NET Core based integration layer that exposes secure REST endpoints for Eclipse data and business logic, with get, insert and update activities. That is the supported door for an integration that creates orders. Epicor EDI handles customers who already trade electronically. And for document driven orders Epicor points Eclipse customers to a partner: in July 2026 Epicor and Conexiom announced an expanded partnership covering sales orders, requests for quotes, AP invoices and vendor acknowledgements for Eclipse and Prophet 21. All of those routes share one requirement. The order has to be structured data before Eclipse will take it.

What Eclipse has to resolve on every order

A customer PO carries what the buyer knows: their company name, a PO number, a ship-to address, their part numbers, quantities, units, prices and a need-by date. Eclipse runs on its own records. The integration notes published for Eclipse order automation list the checks a clean order has to pass, and they are a useful map of where hand keyed orders go wrong:

• Customer. The buyer name, street and postal code on the document are matched to an Eclipse customer ID.
• Ship-to. The delivery address is matched to a ship-to record under that customer. A contractor with thirty open jobs has thirty of them.
• Product. The Eclipse product ID is found from the customer number and the part number the buyer printed, which is why customer part number cross references matter so much.
• Unit of measure. The unit on the PO has to match a unit that exists for that product.
• Unit price. The price on the PO is compared with the Eclipse price inside a tolerance you set.
• Quantity and date. Quantity is checked against the minimum order quantity, and the due date has to be in the future.
• Total. The PO total is compared with the sum of the lines, again inside a tolerance.

None of those checks can start until the document is data. That is the step PurchaseOrders handles. It reads the PO and returns the header and every line as rows, with the buyer part number, your part number when the buyer printed it, the description, quantity, unit, unit price and extended amount in separate columns. Your rep, your spreadsheet lookup or your API integration then does the matching against Eclipse.

Why line items decide whether this works

Distribution orders are long. A commercial electrical job can run to 80 lines of conduit, fittings, wire and devices, and a plumbing rough-in order is not much shorter. Buyers abbreviate, mix catalog numbers with their own stock numbers, and wrap descriptions across two lines. Units are the quiet problem: wire by the foot or by the reel, fittings by the each or by the box, pipe by the length or by the foot. A reel of 500 keyed as 500 eaches is a pricing error nobody sees until the customer disputes the invoice. Having quantity, unit and price side by side for every line, in the order the buyer printed them, is what lets a rep catch that in seconds instead of after shipment. The detail on how tables are read is on the purchase order line item extraction page.

What a morning looks like with it

The shared orders inbox has 35 purchase orders by 8 a.m. Someone saves the attachments and drops them into bulk purchase order upload, up to 50 files at a time. A few minutes later there is one workbook with a row per line and the PO number on every row. The rep sorts by customer, pastes the buyer part numbers through the cross reference, and enters or loads the orders into Eclipse with the lines already in front of them. Orders that would have taken until noon are in before the first truck cut-off. Nothing about pricing, credit, branch or fulfillment logic in Eclipse changes.

Who uses this

Inside sales and order desk managers at US electrical, plumbing, HVAC and PVF distributors on Epicor Eclipse whose customers still send purchase orders as PDFs, from a handful a day at one branch to several hundred a week across a region. They pay to stop keying lines, to get orders in before the cut-off, and to stop the wrong unit and wrong ship-to errors that come back as credits. If the business runs Prophet 21 instead, the same workflow is on Prophet 21 order entry automation, and Kinetic users have Epicor sales order import with DMT. The system-neutral version is sales order entry automation, and if you are weighing the enterprise platforms first, we compared the two that distributors shortlist most in Conexiom vs Esker for order automation.

What it does not do

PurchaseOrders does not connect to Epicor Eclipse, does not call the Eclipse API, does not validate against your customer or product files and is not an EDI translator. It reads customer purchase orders and returns Excel, CSV or JSON. Matching to Eclipse customers, ship-tos and products, and creating the order, stays with your order desk or with an integration your Epicor partner builds. Your pricing matrix, contracts, credit holds and branch rules stay exactly as they are.