How to automate email into abas ERP
Short answer
Watch a shared mailbox, classify each message, extract structured fields with a model, match them to abas customers, items and open documents, and create a draft or a review task through EDP or the REST API. A person approves before anything posts.
In many abas shops the real order entry channel is still email. A customer sends a PDF purchase order, a supplier replies with a revised date in free text, a distributor asks for a quote on a list of part numbers. Someone retypes it into abas, usually with a delay and the occasional wrong item number.
Email automation here means reading those messages and attachments, turning them into the same data an order clerk would enter, and putting the result in front of that clerk for a quick check. It is rarely about full autonomy. It is about removing the retyping and the inbox hunting.
The abas-specific work is in matching: customer numbers, item numbers and customer-specific part numbers, and in choosing the right document type and entry path so the result looks like something a user entered.
What teams use it for
Customer PO to sales order draft
Read a PDF or body-text purchase order, extract lines, match items through customer part numbers, and create a draft sales order for review.
Supplier confirmation to purchase order update
Parse 'we can deliver 12 pieces on the 18th' replies and propose a delivery date or quantity change on the matching purchase order line.
RFQ intake
Extract requested parts, quantities and deadline from an inquiry, create a draft quotation, and flag items that need engineering input.
Invoice routing
Detect vendor invoices in an AP mailbox, extract header data, and queue them for the document OCR and approval path.
Exception triage
Classify complaints, change requests and cancellations and route each to the right person with the related abas order already looked up.
abas ERP integration surface
- EDP interface for creating and editing documents such as inquiries, quotations and sales orders from a service; exact calls depend on the abas release and your database setup.
- REST API on newer releases where write endpoints may exist; verify which document types can be created in your version.
- Customer and vendor records plus customer-specific part number and cross-reference data, which is the heart of reliable matching.
- Infosystems for read-only lookups of open orders and purchase order lines, used to match replies to the right document.
- Document attachments in abas, so the original email and PDF can be linked to the created record for audit.
How it works
- 1
Connect the mailbox
Use Microsoft Graph, Gmail API or IMAP against a shared mailbox such as orders@. Process messages idempotently and move them to a processed folder with a message id log.
- 2
Classify and filter
A small model or rules decide: order, confirmation, invoice, inquiry, other. Ignore newsletters and auto-replies before spending any model time.
- 3
Extract fields
Parse body and attachments. Ask a model for strict JSON: sender, reference number, lines, quantities, dates, currency. Reject outputs that fail schema validation.
- 4
Match to abas
Resolve the customer from the sender domain and reference, map lines through item numbers or customer part numbers, and attach a confidence score to each match.
- 5
Create a draft or a task
Above the threshold create a draft document through EDP or REST. Below it, create a review task listing what is uncertain. Never auto-post on first release.
- 6
Review and learn
Show the clerk the original next to the draft, record corrections, and add confirmed cross-references to the mapping table so the next email matches better.
Example flows
PDF purchase order from a repeat customer
Trigger: An email with PDF arrives in the orders mailbox.
- Classifier marks it as a purchase order.
- Extractor returns eight lines with customer part numbers.
- Matcher resolves seven lines and flags one unknown number.
- A draft sales order is created with a note on the flagged line.
Result: The clerk fixes one line and releases the order instead of typing eight.
Supplier moves a date
Trigger: A supplier replies 'delivery moves to week 41'.
- The reply thread id is matched to the purchase order that triggered the original message.
- The model extracts the new week and converts it to a date.
- A proposed change is recorded in a review field on the order line.
- The buyer accepts it and abas updates the expected date.
Result: Delivery dates stay current without the buyer scanning the inbox.
Keeping data on-prem
Email content is often confidential, and attachments may include drawings or pricing. Run the extraction model on your own server, for example an open-weight model served with vLLM or Ollama, and keep the whole pipeline inside the network: mailbox connector, parser, matcher and the abas write path. If the mailbox is cloud-hosted, only the mail fetch crosses the boundary, and extraction results stay inside. The matcher reads abas through a service account with read-only rights plus a restricted right to create drafts, so even a faulty extraction cannot touch posted documents.
Security checklist
- Treat email as untrusted input: strip active content, scan attachments, and never let message text act as instructions to the system.
- Limit the service account in abas to create drafts and read lookups, and log every created record with the source message id.
- Validate sender domains and watch for spoofed supplier bank detail changes, which must always go to a human.
- Retain originals and extraction results for audit, with a defined retention period.
- Keep model prompts and outputs in your own logs, not in a third-party service, when mail contains confidential data.
Ways to get it done
Generic email parsing service plus an import file
Effort: Days to weeks, brittle if formats change.
Stable, templated customer formats where a fixed layout is enough.
Build with a model and an EDP or REST writer in-house
Effort: About 6 to 10 weeks to reach reliable drafts.
Varied formats, an internal developer, and need for control over matching.
Partner build such as Netray
Effort: A scoped pilot on one mailbox, then extension.
You want a private model, confidence thresholds, a review screen and measured accuracy before go-live.
Pitfalls
- !Skipping customer part number cross-references, which is where most mismatches come from.
- !Auto-posting orders before accuracy has been measured on real mail.
- !Reprocessing the same message after a restart because there is no idempotency key.
- !Ignoring units of measure and packaging quantities during extraction.
- !Treating payment or bank detail change emails like ordinary orders.
Frequently asked questions
Can abas create sales orders from email out of the box?
Not in a way we can confirm as standard. Most sites build a pipeline that extracts the data and creates a draft through EDP or REST, or they use an import tool with a fixed format. Check what your version and add-ons provide.
How accurate is extraction?
It depends on how clean the sources are. Machine-generated PDFs from repeat customers can be very reliable, while photographed or handwritten orders are not. Measure on a sample of your real mail and set thresholds accordingly.
Do we need to send our emails to a cloud AI?
No. An open-weight model on your own server can handle classification and extraction for most business mail. Cloud models are optional, and you should decide based on your data policy.
What happens when the match is uncertain?
The pipeline creates a review task instead of a document. It lists the candidate customers or items with scores so the clerk can choose, and the choice is saved for future matching.
Can it reply to the sender?
Yes, but start with drafts that a person sends. Automatic acknowledgements are fine once the order is created and checked, but replies containing prices or promises should stay under human control.
Want Email automation working on your abas ERP?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment