How to automate email-to-order entry in Sage 100
Short answer
Read the shared inbox with Microsoft Graph or IMAP, extract the document with a language model or rules, match customer and items against Sage master data, and stage a draft sales order or acknowledgement. A person approves and a Business Object Interface call creates the transaction.
A lot of Sage 100 revenue arrives as a PDF attached to an email. A customer sends a purchase order, a distributor sends a reorder list in the body, a vendor replies with an acknowledgement and a changed date. Someone then retypes it into Sales Order Entry.
The work is repetitive but not trivial, because every customer formats differently, uses their own part numbers, and sometimes asks for things Sage cannot do by default. A pure template approach breaks as soon as a customer changes their layout.
That is why a combination works best: language-model extraction for the messy reading, strict validation against Sage master data, and a human check before anything posts.
What teams use it for
Customer PO to sales order
Extract customer PO number, ship-to, lines, quantities and requested dates, then create a draft sales order for review.
Vendor acknowledgement updates
Match acknowledgements to open PO lines by PO number and item, and propose promise-date changes for the buyer.
RFQ intake and quoting
Detect an RFQ email, resolve parts, and prepare a quote draft with current pricing for the sales rep.
Order change and cancel requests
Recognise 'change qty on PO 8841' messages, find the sales order, and queue a change request instead of auto-editing.
Remittance advice matching
Read remittance emails and suggest cash receipt matches by invoice number for the AR clerk.
Sage 100 integration surface
- Business Object Interface (COM): create sales orders, change lines and perform cash receipts with Sage validation. It is the right way to post, rather than writing to tables.
- ODBC or SQL reads: resolve customers (AR_Customer), items (CI_Item), customer-specific item codes, and open sales orders and POs for matching. Premium on SQL Server is quicker; Standard and Advanced use ProvideX behind ODBC.
- Visual Integrator: import jobs for sales orders or other data from a prepared file. A fallback when COM hosting is awkward; keep the job in a staging mode so a person triggers it.
- Paperless Office and document attachment features: keep the source PDF linked to the order for audit; exact capabilities depend on version and settings.
- Sage CRM or other add-ons, if installed, may hold quote data worth cross-checking.
How it works
- 1
Connect the mailbox
Use Microsoft Graph with application permissions limited to one shared mailbox, or IMAP. Move processed messages to folders so you never lose an item.
- 2
Classify and extract
Decide if a message is a PO, acknowledgement, RFQ or noise. Extract header and lines, preferring structured data when an EDI-like attachment exists.
- 3
Match against Sage
Resolve the sender to a customer, convert customer part numbers via item cross-references, and flag unknown parts. Never invent an item.
- 4
Score confidence
Check totals, quantities and dates for consistency and compare unit prices with the customer's expected price. Low confidence goes to a review queue.
- 5
Stage a draft and show the source
Present the extracted fields next to the PDF so the clerk corrects and approves in seconds.
- 6
Post through BOI and reply
On approval, create the transaction, attach the document, and send an order acknowledgement from a template.
Example flows
Recurring customer PO
Trigger: A PDF purchase order arrives at orders@ from a known customer.
- The classifier tags it as a PO and extracts lines.
- Customer part numbers are mapped to Sage item codes; one line is unknown.
- The draft is queued with that line highlighted.
- The clerk fixes the item, approves, and BOI creates the order with the PDF attached.
Result: Keying time drops and the unknown-part exception is caught instead of guessed.
Vendor delay notice
Trigger: A vendor emails that PO line 3 will ship ten days late.
- The message is matched to the PO by number and item.
- A proposed new promise date is staged for the buyer.
- The buyer approves and the PO line is updated.
- Affected sales orders are listed for the account manager.
Result: Delays reach planners the same day, not at the next receiving check.
Keeping data on-prem
Order emails contain customer names, pricing and part numbers, so many manufacturers do not want them sent to a hosted AI service. The extraction can run on an open-weight model in your own server room, reading from a mailbox you control and writing drafts into a staging database next to Sage. The Sage connection stays on the LAN, with ODBC for reads and BOI for posting. Only the mail transport leaves your network, and if your mail is on-prem Exchange even that can stay internal. A vision model or an OCR step may be needed for scanned attachments, which should also run locally.
Security checklist
- Restrict mailbox access to the specific shared mailbox, not the whole tenant.
- Treat email content as untrusted input; a message must never be able to trigger an action by instruction text.
- Check sender identity and domains, and beware of spoofed vendor bank or address changes.
- Keep source emails and extracted data tied to the transaction for audit.
- Post under a dedicated Sage user that is logged in the audit trail.
Ways to get it done
Rules and templates per customer
Effort: Days per customer; brittle when layouts change.
A handful of large customers with stable formats.
Build an LLM extraction pipeline in-house
Effort: Four to eight weeks to get review queue and BOI posting stable.
Teams with a developer and appetite for validation work.
Partner-delivered pipeline with private models
Effort: A few weeks for a first scoped mailbox.
You need on-prem processing, review UI and Sage posting without building it.
Pitfalls
- !Auto-posting with no review, so one misread quantity becomes a shipped order.
- !Ignoring unit of measure differences between the customer's PO and the Sage item.
- !Failing to detect duplicate POs when a customer resends the same email.
- !Missing ship-to matching, which sends goods to the bill-to address.
- !Treating the pricing on the customer's PO as the truth instead of comparing to Sage price levels.
Frequently asked questions
Can Sage 100 read emails by itself?
Not for order entry. Sage can send emails, for example documents through Paperless Office, but it does not parse inbound messages. An external pipeline reads the mailbox, extracts data and hands a draft to Sage through the Business Object Interface.
Should orders post automatically?
Only after a track record. Start with every draft reviewed, then allow auto-post for a customer when extraction has matched cleanly for a long stretch, with totals and price checks as guardrails.
How are customer part numbers handled?
Through a cross-reference lookup against Sage's customer item data, falling back to a review prompt. The pipeline should never guess an item code, since a wrong match produces a wrong shipment.
Does this need an EDI subscription?
No, but if a customer can send EDI, that is more reliable than parsing PDFs. Email extraction is the practical option for the many customers who will never move to EDI.
Can the extraction run locally?
Yes. Open-weight text and vision models can run on a modest GPU server and keep order content inside your network. Accuracy should be measured on your own sample documents before relying on it.
Want Email automation working on your Sage 100?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessmentTry it here, free
Sage 100 Business Object Interface (BOI) Sales Order Script Generator
Produces a working PowerShell script that logs in to Sage 100 through BOI, creates a sales order with one line and reports Sage's own error message on failure.
New to Sage X3 and Sage 100? Start with the Sage X3 and Sage 100 guide and toolkit.
Keep exploring
Free tools
- Sage 100 Business Object Interface (BOI) Sales Order Script GeneratorProduces a working PowerShell script that logs in to Sage 100 through BOI, creates a sales order with one line and reports Sage's own error message on failure.
- Sage 100 to Cloud Migration AssessmentA 10-question readiness score for companies on Sage 100 deciding when and how to move to a cloud ERP, with recommendations by result band.
- Sage 100 Table and Module Prefix ReferenceFind the Sage 100 module prefix and the commonly used table names for items, customers, vendors, orders and bills of material.
ERP fixes and how-tos
- How to Add User Defined Fields (UDFs) in Sage 100How to add a user defined field in Sage 100 with Custom Office, place it on a panel, and expose it to reports, ODBC and imports, with the usual UDF pitfalls.
- Sage 100 Business Object Interface (BOI): Working VBScript ExampleWorking Sage 100 BOI pattern: ProvideX.Script, SY_Session logon, nSetCompany, reading a customer and writing records, plus the errors and security settings that break it.
- How to Void a Check in Sage 100Void an AP check in Sage 100 through Check and Payment Voiding: reverse the GL entry, reopen the invoice, and handle closed periods or checks that already cleared.
AI on your ERP
- AI for Sage 100 Small Manufacturers: Practical Answers From Work Orders, BOMs and InventoryPractical AI for small manufacturers on Sage 100: ask about work orders, BOMs, stock and shortages in plain English via ODBC or SQL, kept on a small server.
- AI for Sage 100, Grounded in Your MAS90/200 DataPut AI on Sage 100 and the Sage 100 Manufacturing (MRP) data set without sending data to a public model. Private LLMs and agents grounded in your MAS90/200 tables.
Integrations
- How to automate email in Sage X3Turn inbound customer POs, RFQs and supplier confirmations from shared inboxes into Sage X3 transactions with review, using web services and import templates.
- How to add AI agents to Sage 100How to add AI agents to Sage 100: a tool layer over ODBC and the Business Object Interface, approval-gated writes, and on-prem models for MAS 90/200 shops.