How does ml-connector detect new EDI documents arriving in IBM Sterling?

IBM Sterling has no outbound webhooks, so ml-connector polls the mailbox API at regular intervals (every 1 to 5 minutes, configurable). Each poll checks for new messages by comparing their arrival timestamps, extracts the EDI payload, and queues the document for mapping and posting to Visma. You control the polling interval to balance latency and throughput.

What EDI standards does ml-connector support, and how are documents mapped to Visma?

ml-connector decodes ANSI X12, EDIFACT, TRADACOMS, and other standards that IBM Sterling receives. EDI 850 (purchase orders) map to Visma PurchaseOrders, and EDI 810 (invoices) map to SupplierInvoices. Customer-provided mapping rules route each document to the correct GL accounts and dimensions in Visma based on supplier ID, item code, or other fields in the EDI header.

Does Visma's requirement for an ipp-company-id header on every API call affect the integration?

No. ml-connector includes the tenant ID in the ipp-company-id header on every Visma API call as part of the OAuth 2.0 credential set. The client_id, client_secret, and tenant_id are stored encrypted, and the header is populated automatically for every request.

VismaIBM Sterling

Visma and IBM Sterling integration

Visma.net ERP is your general ledger and AP hub. IBM Sterling B2B Integrator is your partner-facing EDI gateway. Connecting the two keeps your purchasing and invoicing synchronized with your supply chain, without manual re-keying or translation. Incoming EDI purchase orders and invoices flow straight into Visma, translated to native GL documents. Outgoing documents from Visma route to your trading partners through the EDI standard and transport protocol each one expects.

How Visma works

Visma.net ERP exposes suppliers, purchase orders, supplier invoices, accounts, dimensions, journal transactions, and cash transactions through REST APIs over HTTPS. Authentication uses OAuth 2.0 client credentials grant against the Visma Connect token endpoint, with tenant identity carried in the ipp-company-id header on all calls. Visma.net supports both webhooks (one-time delivery, no retry) and polling via lastModifiedDateTime query parameters. Webhook delivery is unreliable and must be explicitly enabled per entity type at the company level.

How IBM Sterling works

IBM Sterling B2B Integrator is deployed on-premises or in a customer-managed cloud, so there is no shared public endpoint; the customer provides the host and port. It exposes trading partners, mailbox messages, documents, workflows, and routing rules via a REST API secured with HTTP Basic Auth or OAuth 2.0, both local to the customer instance. Sterling has no outbound webhooks. Documents inbound from trading partners arrive as EDI payloads inside mailbox messages, polled via GET /B2BAPIs/svc/mailboxMessages/ on a schedule, and extracted via a separate payload endpoint.

What moves between them

Inbound EDI documents arrive at IBM Sterling from trading partners via SFTP, AS2, EDIFACT, ANSI X12, or other protocols the customer has configured. ml-connector polls Sterling's mailbox API at regular intervals (every 1 to 5 minutes), detects new messages, and extracts the EDI payload. The EDI content is parsed and mapped to Visma entities: purchase orders (EDI 850) become PurchaseOrders in Visma, supplier invoices (EDI 810) become SupplierInvoices, and advance shipment notices (EDI 856) are logged for reference. Outbound documents created in Visma (new invoices, payment instructions, order confirmations) are formatted as EDI and handed to Sterling for translation and delivery to each partner's preferred protocol.

How ml-connector handles it

ml-connector maintains two encrypted credential sets: the Visma.net OAuth2 client credentials and tenant ID, and the IBM Sterling host, port, and HTTP Basic or OAuth2 credentials. On the Visma side, it obtains a bearer token via the Visma Connect endpoint and includes the ipp-company-id header on every Visma API call per the tenant model. On the Sterling side, it polls the mailbox API at intervals you define, detects new messages by comparing arrival timestamps, and extracts payloads one at a time. EDI 850 and 810 documents are decoded into a standard format, mapped to Visma dimensions (cost centers, accounts) via customer-provided routing rules, and posted to Visma as PurchaseOrders or SupplierInvoices. Outbound Visma documents are fetched on a schedule, formatted as EDI 850 or 810 depending on document type, and handed to Sterling with a target trading partner identifier. Sterling handles translation to the partner's required EDI standard, encryption, and transmission via the protocol that partner has registered (SFTP, AS2, EDIFACT, X12, or other). Visma token refresh is handled automatically when expiry is near. Sterling polling intervals are tunable so you control latency and throughput. Every document carries a full audit trail in both systems.

A real-world example

A distribution company uses Visma.net for accounting and purchase order management, and maintains a network of 50+ suppliers and customers that communicate via EDI. Before integration, the purchasing team received EDI 850 purchase orders from downstream customers into their IBM Sterling instance, printed them, and manually entered them into Visma.net, then matched incoming invoices by hand. With Visma and Sterling connected, inbound EDI orders land as live purchase orders in Visma within minutes, supplier invoices are matched automatically, and outgoing confirmations and advance shipment notices flow back to partners without a single manual step. The AP team's workload on invoice matching dropped 70%, and month-end reconciliation is now automated.

What you can do

Parse EDI purchase orders (850) and invoices (810) arriving in IBM Sterling and post them directly to Visma.net as PurchaseOrders and SupplierInvoices.
Route inbound EDI documents to the correct Visma cost centers, dimensions, and GL accounts based on customer mapping rules.
Send outbound documents from Visma to IBM Sterling for translation and transmission to each trading partner via their registered protocol (SFTP, AS2, EDIFACT, X12).
Manage OAuth2 and Basic Auth credentials for both systems encrypted at rest, with automatic token refresh for Visma and configurable polling intervals for Sterling.
Maintain a complete audit trail of every document processed, with the ability to replay or reroute documents if a downstream system is unavailable.

Questions

How does ml-connector detect new EDI documents arriving in IBM Sterling?: IBM Sterling has no outbound webhooks, so ml-connector polls the mailbox API at regular intervals (every 1 to 5 minutes, configurable). Each poll checks for new messages by comparing their arrival timestamps, extracts the EDI payload, and queues the document for mapping and posting to Visma. You control the polling interval to balance latency and throughput.
What EDI standards does ml-connector support, and how are documents mapped to Visma?: ml-connector decodes ANSI X12, EDIFACT, TRADACOMS, and other standards that IBM Sterling receives. EDI 850 (purchase orders) map to Visma PurchaseOrders, and EDI 810 (invoices) map to SupplierInvoices. Customer-provided mapping rules route each document to the correct GL accounts and dimensions in Visma based on supplier ID, item code, or other fields in the EDI header.
Does Visma's requirement for an ipp-company-id header on every API call affect the integration?: No. ml-connector includes the tenant ID in the ipp-company-id header on every Visma API call as part of the OAuth 2.0 credential set. The client_id, client_secret, and tenant_id are stored encrypted, and the header is populated automatically for every request.

Connect Visma and IBM Sterling

Free to use. Add your credentials, ping your real systems, and see if we fit.

Get started