Email automationBaan IV / Baan V Agent view

How to automate email in Baan IV / Baan V

Short answer

Read the shared inbox with a service, classify and extract fields from order emails and attachments, match them to Baan customers, items and orders, and put the result in a review queue. Approved rows go into Baan through data exchange, EDI import or AFS, never by direct table writes.

Baan sites are often small or mid-size manufacturers with a long tail of customers who still send purchase orders as PDF or Excel attachments, and suppliers who confirm by email. Order entry clerks retype the same fields into the sales order session every day, and the shared orders@ mailbox is the real front door of the ERP.

Baan itself has no email ingestion. The EDI module handles structured formats from partners who can do it, but the long tail cannot. That gap is where email automation pays.

The goal is not zero touch. It is to turn a clerk from typist to reviewer: the system proposes a draft order with confidence flags and the clerk fixes the exceptions.

What teams use it for

Customer PO to sales order draft

Extract customer PO number, ship-to, lines, quantities and requested dates, match customer part numbers to Baan items through a cross-reference, and create a draft for review.

RFQ intake

Detect requests for quotation, pull specs and quantities, and open a quotation record or task for estimating with the attachments filed.

Supplier acknowledgement capture

Match confirmations to open PO lines by PO number and update confirmed dates in a staging table for the buyer to accept.

Order change requests

Recognise 'please change quantity on line 2' emails, link them to the existing order, and show current versus requested values to the clerk.

Shipping and carrier emails

Parse tracking numbers from carrier mail and attach them to the shipment record or a notes table.

Baan IV / Baan V integration surface

  • Baan EDI module and data exchange: file-based, mapped import of sales orders and purchase order acknowledgements. Often the safest way to create transactions from extracted email data.
  • Application Function Server (AFS): programmatic entry into Baan sessions with their validation, useful where a mapped file import is too rigid.
  • Cross-reference tables for customer item numbers and for business partner identifiers, whose structure varies by implementation and often needs cleansing.
  • Read-only database access for matching: validating customer codes, open order numbers, item masters and unit-of-measure before the proposal is shown.
  • Document storage: Baan has limited native attachment handling, so original emails and PDFs are usually stored on a file share or document system and referenced by key.

How it works

  1. 1

    Connect to the mailbox

    Use IMAP or Microsoft Graph with a service account scoped to the shared mailbox. Move processed mail to a folder and keep the original immutable.

  2. 2

    Classify each message

    Decide whether it is a PO, RFQ, acknowledgement, change request or noise. A small model or rules plus a model works well, with an 'unknown' bucket for humans.

  3. 3

    Extract fields

    Parse body text, Excel and PDF attachments into a structured record. Include a confidence score per field and the source location so a reviewer can verify quickly.

  4. 4

    Match to Baan master data

    Resolve customer, ship-to, items and units using the cross-reference tables and fuzzy matching. Unmatched items become explicit exceptions rather than guesses.

  5. 5

    Review queue

    Present the proposal next to the original document. A clerk edits, accepts or rejects. Track edit rates to learn where extraction fails.

  6. 6

    Import and reconcile

    Generate the import file or AFS call for accepted proposals, capture Baan's response (order number or error) and reply to the sender if required.

Example flows

PDF purchase order arrives

Trigger: A customer emails a PDF PO to the orders mailbox.

  1. Service classifies it as a purchase order and extracts header and lines.
  2. Customer and items are matched using the cross-reference.
  3. One line has a price that differs from Baan's price list and is flagged.
  4. Clerk fixes the flag and accepts.
  5. Import creates the sales order and the service emails an acknowledgement with the Baan order number.

Result: A ten-minute typing job becomes a two-minute review with a price discrepancy surfaced rather than missed.

Supplier confirms with a changed date

Trigger: A supplier replies to a PO email with new dates.

  1. Service finds the PO number and matches lines.
  2. New dates appear next to current promised dates in the buyer's queue.
  3. Buyer accepts, and the import updates the PO line.

Result: Delivery dates in Baan reflect reality, which improves MRP output.

Keeping data on-prem

Order and pricing emails are commercially sensitive, so the extraction models should run where the mail already lives. Host the service on a server inside your network or in your private cloud, use an open-weight model served locally for classification and extraction, and store originals and proposals in your own database. Baan and its database never need to be exposed; the service connects to them from inside. If you use a Microsoft 365 mailbox, the service only pulls mail through Graph and sends nothing else to third parties. Air-gapped sites can use an on-prem mail server and the same pipeline.

Security checklist

  • Use a least-privilege mailbox account and block automated replies to untrusted senders.
  • Treat attachments as untrusted: scan for malware, strip macros and limit file types and sizes.
  • Guard against prompt injection in email bodies. Extracted text is data and must never trigger actions or tool calls.
  • Require human review for new customers, large values and any change in bank or ship-to details.
  • Keep the original email, extraction output, reviewer edits and the import result for audit.

Ways to get it done

Use Baan EDI plus customer onboarding to EDI/portal

Effort: Slow per partner but removes the need for extraction; combine with email automation for the tail.

High-volume customers who can be moved to structured formats.

Generic intelligent document processing product

Effort: Weeks, with Baan matching and import the main custom work.

Sites with a licence already and someone to build the Baan import side.

Custom pipeline with a partner like Netray

Effort: Scoped as a project; usually one mailbox and one document type first, then expansion.

When you want private models, Baan-aware matching and a review UI tuned to your mailbox.

Pitfalls

  • !Customer item numbers often live in free text fields or in a spreadsheet nobody owns. Fix the cross-reference first.
  • !Unit of measure and packaging mismatches create plausible but wrong quantities. Validate against item master units.
  • !Reply chains contain old quoted PO text. Extract only from the latest message and the attachments.
  • !Auto-acknowledging before Baan accepts the import sends customers numbers that may not exist. Reply only after a successful import.
  • !Skipping the review stage early to save time produces silent errors that surface weeks later in MRP.

Frequently asked questions

Can Baan read emails by itself?

No. Baan has no native mailbox ingestion. The EDI module handles structured partner messages, but unstructured email needs an external service to read the mailbox, extract data and prepare an import. The service then feeds Baan through data exchange, EDI import or AFS so normal validation applies.

How accurate is extraction on messy PDFs?

It varies by document quality and layout. Clean text PDFs from repeat customers can reach very high field accuracy, while scans and odd layouts need more review. The right measure is edit rate in your review queue over a few weeks, and thresholds can be set so only high-confidence fields are pre-accepted.

Should it create orders automatically?

Start with drafts and review. After a customer's documents run clean for a while, you can auto-accept their orders when every check passes, such as known items, price within tolerance and no change in terms. Keep new customers, unusual quantities and credit-held accounts under human review indefinitely.

Does this work with Outlook, Gmail or an on-prem mail server?

Yes. The service connects through Microsoft Graph, IMAP or Exchange access, depending on your set-up, using a service account. Because it works on mail rather than on Baan, the mail platform does not affect how Baan is updated. Check your mail admin's policy on app access and multi-factor requirements.

What about orders already in EDI?

Keep them in EDI. Structured feeds are more reliable than any extraction. Use email automation for the customers who cannot or will not send EDI, and use the same Baan import path for both so downstream processes, such as order acknowledgements and planning, behave identically.

Want Email automation working on your Baan IV / Baan V?

A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.

Get a free assessment