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 assessment