Visma and Stedi integration

What moves between them

Purchase orders and supplier invoices flow from Visma into Stedi, where ml-connector transforms them into X12 850 and 810 documents and posts them as JSON, Stedi then converts them to EDI and routes them to your partners via SFTP or AS2. Inbound EDI from partners (855 PO Acknowledgments, 856 Advance Shipment Notices, 810 invoices from suppliers) arrives at Stedi, is parsed to JSON, and ml-connector reads it via webhook or polling and posts the data back to Visma as purchase receipts and supplier invoice records. The sync runs on a schedule you control, with full traceability for every record.

How ml-connector handles it

ml-connector stores the Visma OAuth credentials and Stedi API Key encrypted and refreshes the Visma token before expiry on each sync cycle, using the tenant_id and company-id headers as required. It reads Visma purchase orders and invoices using delta-pull with lastModifiedDateTime, transforms them into Stedi-compatible JSON with all required X12 segments, and posts them with an Idempotency-Key header so retries do not create duplicates. On inbound, ml-connector receives Stedi webhook notifications for parsed EDI (850, 810, 856, 855 documents) as JSON and posts them back to Visma as purchase receipts and supplier invoice records, mapped to the correct Visma suppliers and GL accounts. Because Visma webhooks are one-time delivery with no automatic retry and Stedi's are reliable with 4-retry backup, ml-connector uses Visma polling as the primary source and Stedi webhooks as the accelerator, so no transaction is missed. Every record carries source and destination IDs for traceability, and failed posts can be replayed.

A real-world example

A mid-sized Nordic goods manufacturer uses Visma.net ERP for procurement and accounting, and connects to suppliers worldwide via EDI. Before the integration, the procurement team exported purchase orders and invoices from Visma each day, manually converted them into X12 format using a third-party tool, and uploaded them to Stedi via SFTP, then performed the reverse for inbound supplier EDI. With Visma and Stedi connected, each purchase order or invoice created in Visma appears in Stedi seconds later in X12 format, routed automatically to the correct supplier via their preferred EDI transport. Inbound acknowledgments and shipment notices from suppliers flow back into Visma as purchase receipts without manual intervention, so the ledger stays current and the procurement team spends their time on strategy, not file preparation.

What you can do

• •Read purchase orders and invoices from Visma, transform them to X12 format, and post them to Stedi for partner delivery.
• •Receive inbound EDI transactions (850, 810, 856, 855) from Stedi, parse them as JSON, and post them into Visma as purchase receipts and supplier invoices.
• •Manage Visma OAuth token refresh and Stedi API Key rotation, storing both encrypted with full audit trail.
• •Deduplicate outbound writes to Stedi using Idempotency-Key headers and track inbound transaction IDs to prevent duplicate posts to Visma.
• •Poll Visma on a schedule for changed orders and invoices, with Stedi webhook acceleration for faster inbound EDI delivery.

Questions

Which direction does data move between Visma and Stedi?

Both directions. Purchase orders and invoices move from Visma into Stedi for conversion to X12 and delivery to partners via SFTP or AS2. Inbound EDI from Stedi (Advance Shipment Notices, invoices from suppliers, PO acknowledgments) flows back into Visma as purchase receipts and supplier invoice records. Reference data such as suppliers and GL accounts are read from Visma and used to map inbound EDI.

How does ml-connector handle Visma's one-time webhook delivery?

Visma webhooks are one-time delivery with no automatic retry, so ml-connector does not rely on them as the primary sync mechanism. Instead, it polls Visma on a regular schedule using the lastModifiedDateTime parameter to catch all changed orders and invoices. Stedi webhooks are more reliable with 4-retry backup, so inbound EDI from Stedi is received via webhook and accelerates the sync without waiting for the polling cycle.

How are inbound EDI documents from Stedi mapped to Visma records?

ml-connector reads the supplier ID, invoice number, or PO reference in the parsed EDI JSON from Stedi and matches it against Visma suppliers and purchase orders. It then extracts line items, amounts, and tax details and posts them to Visma as purchase receipt or supplier invoice records on the matched supplier and GL account. If a supplier or GL account does not exist in Visma, the record is logged with an error and can be replayed once the dimension is created.