Sage 100 and Cleo integration

What moves between them

Purchase orders and vendor master records flow from Sage 100 into Cleo whenever they are created or updated. Supplier invoice confirmations, ASNs, and receipt acknowledgments flow from Cleo back into Sage 100 to close PO line items and trigger receipt posting. GL account and cost center reference data are validated in both directions so invoice accruals land on correct ledger segments. The Sage 100 SOAP layer does not expose AP invoices, GL, or PO data, so ml-connector polls via a local Windows agent wrapping the BOI COM layer, running on the customer's Sage 100 server.

How ml-connector handles it

ml-connector runs on the customer's on-premises network where the Sage 100 server and local agent live, accepting Sage 100 credentials (username, password, company code) and storing them encrypted. It polls Sage 100's BOI layer every 15 minutes for new or updated POs and vendors, and every 4 hours for GL reference data. On the Cleo side, it exchanges Cleo credentials for an OAuth Bearer token before each poll, caching the token until expiry. When a Sage 100 PO is detected, ml-connector posts it as an EDI 850 (purchase order) to Cleo, mapping Sage 100 vendor numbers to Cleo trading partner IDs. Incoming ASNs and invoice confirmations from Cleo are parsed and written back into Sage 100 via the BOI layer using the Sage-supplied next-number helpers to avoid duplicate key collisions. COM record-locking is common, so ml-connector retries failed writes with exponential backoff. Every transaction carries a timestamp and direction marker in the audit log, allowing replays without creating duplicates.

A real-world example

A mid-sized consumer goods distributor runs Sage 100 on-premises for procurement, inventory, and finance across three regional warehouses. They use Cleo to exchange EDI documents with 40+ suppliers and logistics partners, and to sync data to a cloud analytics platform. Before the integration, the supply chain team manually exported POs from Sage 100 into Cleo three times a week, then re-entered supplier confirmations and ASNs back into Sage 100 by hand, creating lag and data mismatches that delayed receipt posting. With Sage 100 and Cleo connected, every new PO in Sage 100 publishes to Cleo instantly (within 15 minutes), suppliers see the order immediately in partner portals, and incoming confirmations flow back into Sage 100 to trigger receipt posting and GL accrual. The supply chain team now spends that time on exception handling and analysis instead of re-keying.

What you can do

• •Publish Sage 100 purchase orders to Cleo on a 15-minute polling cycle, mapping vendors to Cleo trading partner identities.
• •Receive Cleo ASNs and invoice confirmations and post them into Sage 100 via the BOI COM layer.
• •Validate GL accounts and cost centers bidirectionally so invoice accruals land on correct ledger segments.
• •Authenticate Sage 100 with per-call username/password/company-code credentials and manage Cleo OAuth token refresh on each request.
• •Handle COM record-locking with exponential backoff retry, and maintain a replay-safe audit trail for every record.

Questions

How does ml-connector access Sage 100 data if the SOAP API does not expose AP and PO records?

The SOAP Web Services in Sage 100 cover only Sales Orders and Customers (AR). Full AP, GL, and PO access requires the BOI (Business Object Interface) COM layer, which can only be called from a Windows process running on or near the Sage 100 server. ml-connector includes a local agent that runs as a Windows service on the customer's Sage 100 machine, wraps BOI COM calls, and exposes them to the cloud-based ml-connector platform via a secure tunnel.

Does the Sage 100 agent need to run on the Sage 100 server itself?

Yes. Because Sage 100 locks records in COM and enforces concurrent write limits, the agent must run on the same machine as the Sage 100 application or on the same LAN with low-latency access. This also avoids the need to expose the BOI layer over the internet.

How does ml-connector prevent duplicate invoices or POs when it retries failed writes?

Sage 100 supplies next-number helper functions that generate unique document numbers atomically. ml-connector calls these helpers rather than importing external numbers, so a retry on a write failure will never create a duplicate. Every transaction is tagged with a source identifier and timestamp in the audit log, making it safe to replay without side effects.