How to automate email in Sage X3
Short answer
Read a shared mailbox, extract the order, quote request or confirmation with an LLM or parser, validate it against X3 master data, and create the transaction through X3 web services or import templates. A person reviews anything below confidence before it posts.
Most Sage X3 customers still receive a large share of their orders, change requests and supplier confirmations as email: a PDF purchase order, a spreadsheet, a one-line reply saying the date moved. Someone retypes it into X3 sales order entry or updates a purchase order line by hand.
That retyping is slow and error-prone, and it hides in a few people's heads. Automating it is among the highest-value changes you can make on X3, because the target transactions are well defined: sales orders, quotes, purchase order confirmations.
The caution is that inbound email is messy. Customers use their own part numbers, units and ship-to descriptions. The design must match to X3 master data and send uncertainty to a human.
What teams use it for
Customer PO to sales order
Extract customer, PO number, lines, quantities and requested dates, map the customer's part numbers via the customer-item cross reference, and create a draft sales order for CSR review.
RFQ to quote
Read a request for quotation, find the items, and create a sales quote shell with suggested pricing from X3 price lists for the salesperson to finalise.
Supplier acknowledgement to PO update
Parse supplier confirmations of price and date, match them to open PO lines, and propose a change for the buyer to approve.
Order change and cancel requests
Detect a change email referencing an open order, show the diff, and route it to the owner instead of creating new orders by mistake.
Shared inbox triage
Classify mail as order, invoice, complaint, or other, and route each to the right queue so the order desk sees only orders.
Sage X3 integration surface
- Web services: SOAP through the Syracuse web services pool (CAdxWebServiceXmlCC with save and modify) and REST/SData endpoints can create and update sales orders (SORDER) and purchase orders (PORDER). Object and subprogram names depend on version and setup.
- Import/export templates: X3 can import structured files into sales orders and other objects, a safe route when you prefer to drop a validated file rather than call services directly.
- Master data to match against: BPCUSTOMER, ITMMASTER, customer-item cross references (ITMBPC) and price lists; read them through services or a reporting replica.
- Mailbox access: Microsoft Graph or IMAP on the mail side. X3 itself is not the mail reader.
- Staging table: a custom table or external database holds parsed results, confidence and reviewer decisions before posting.
How it works
- 1
Connect the shared mailbox
Use Graph or IMAP with a service identity. Store each message ID so you never process one twice.
- 2
Classify and extract
Classify the email, then extract fields from the body and attachments (PDF text, spreadsheets). OCR is only needed for scanned PDFs.
- 3
Resolve entities against X3
Match the sender or PO header to a customer, map item numbers through cross references, and normalise units and dates.
- 4
Score confidence
Each field gets a confidence value. Unknown items, price mismatches against the price list and new ship-to addresses force review.
- 5
Create a draft or import file
Post via web services into a draft state if your process allows, or generate an import file for the CSR to validate.
- 6
Reply and log
Send an acknowledgement with the X3 order number, link the email to the order, and record the extraction for audit.
Example flows
PDF PO from a regular customer
Trigger: An email arrives at orders@ with a PDF attached.
- Classifier tags it as a customer order; the sender maps to a customer code.
- Lines are extracted and customer part numbers resolved to X3 items.
- Prices are compared with the X3 price list; one line differs.
- A draft sales order is created and flagged for review with the mismatch highlighted.
Result: The CSR checks one line instead of typing twelve and sends the confirmation from X3.
Supplier moves a delivery date
Trigger: A supplier replies to a PO email with a new date.
- The email is matched to the PO by number in the subject or body.
- The line and new date are extracted.
- The buyer sees the proposed change next to current planned receipt.
- On approval, the line date is updated via web service.
Result: Planners see the true receipt date, so MRP stops chasing a date nobody believes.
Keeping data on-prem
Email content often includes pricing and customer-confidential terms, which is exactly what some manufacturers cannot send to a public AI service. Run extraction on an open-weight model hosted on your own GPUs, with the mailbox reader and staging store inside your network. For hosted mail like Microsoft 365, the connector pulls messages into your environment; the model and X3 calls stay private. The system only needs to reach X3 web services internally.
Security checklist
- Treat email content as untrusted input and never let text in a message trigger actions beyond the defined extraction schema (prompt injection).
- Use a service account for X3 with rights to create drafts only.
- Validate sender domains and quarantine mail failing SPF or DKIM checks before extraction.
- Keep attachments and parsed data under your retention policy and encrypt at rest.
- Keep human review on all price, terms and ship-to changes.
Ways to get it done
Use an EDI or order-capture tool plus X3 import
Effort: Weeks per trading partner format.
Customers with stable, structured formats.
Build extraction in-house
Effort: Typically 4 to 10 weeks for a first order flow with review UI.
Teams with data engineers and an X3 developer.
Partner build such as Netray with an X3 partner
Effort: Pilot on one customer group, then widen.
Messy multi-format email and strict on-prem requirements.
Pitfalls
- !Auto-posting orders without review will eventually book a wrong quantity or price at scale.
- !Customer part numbers are unreliable; build and maintain the cross reference.
- !Replies in threads carry quoted old messages that confuse extraction; strip quoted history.
- !Duplicate processing when the same PO arrives twice by email and portal.
- !Draft state handling differs by X3 setup; test how your sales order workflow treats unvalidated orders.
Frequently asked questions
Can Sage X3 read incoming email by itself?
X3 sends mail well but is not designed to read and interpret inbound mail. You add a reader and extraction layer outside X3, then post results through web services or import templates.
Should orders post automatically?
For trusted, repeat customers with high confidence and matching prices, some sites auto-post to a draft. Everything else goes to a person. Start with review on all orders and relax per customer based on measured accuracy.
How do we handle customer part numbers?
Use the customer-item cross reference in X3 and clean it. Where no mapping exists, the system proposes a match from description, and a person confirms it once so the mapping is saved.
Does this need cloud AI?
No. Extraction works on an on-prem open-weight model for most layouts. Cloud models can be more accurate on odd formats, so decide by data sensitivity and test both.
What about EDI?
If a customer can send EDI, use EDI; it is more reliable than email. Email automation is for the long tail of customers who will not or cannot.
Want Email automation working on your Sage X3?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment