Visma and Tradeshift integration

What moves between them

The main flow runs from Tradeshift into Visma. Supplier invoices and purchase order documents are polled from Tradeshift on a schedule (typically daily or on-demand), parsed from UBL XML into line items with quantities, amounts, and cost allocations, and posted into Visma as supplier invoices and GL journal entries. The GL posting is distributed across the cost centers and GL accounts specified in each UBL line, so a single invoice with multiple cost allocations generates multiple GL lines. Supplier master records from Tradeshift are optionally synced to Visma as supplier master data. Invoice status changes (acknowledged, rejected, paid) on Tradeshift are polled and reflected in Visma so the accounts payable record stays current.

How ml-connector handles it

ml-connector polls Tradeshift using OAuth 1.0a signing for every request, including the required X-Tradeshift-TenantId header, and filters for documents changed since the last poll using the changedAfter timestamp. UBL documents are parsed to extract line item details, including cost allocations embedded in each line. For each invoice, ml-connector maps the supplier name and ID from Tradeshift to the corresponding Visma supplier, looks up the GL account and cost center (dimension) for each line's cost allocation, and posts a multi-line supplier invoice into Visma via OAuth 2.0 with the required ipp-company-id header. Journal transactions are created with ETag handling to ensure optimistic locking on write. Visma's single-use webhook notifications are not relied upon, since webhook retries are not automatic; instead ml-connector polls regularly to catch invoice updates. If a supplier does not exist in Visma, the record is queued and flagged in the audit trail; the user adds the supplier and the record is automatically replayed. Tradeshift and Visma use different OAuth flows (1.0a vs 2.0), so ml-connector stores both credential sets encrypted and manages token state separately for each platform.

A real-world example

A mid-sized Nordic manufacturing company uses Visma.net ERP for accounting and Tradeshift to manage a network of international suppliers and coordinate purchases. Before the integration, the accounts payable team downloaded invoices from Tradeshift, reviewed the supplier details and cost allocations, and manually entered each invoice into Visma, allocating line items to the correct cost center or project code. This process took 3 to 5 hours per day and introduced re-entry errors. With Tradeshift and Visma connected, invoices arrive in Visma automatically from Tradeshift, cost allocations are preserved from the supplier's UBL document, and the AP team can review and approve invoices directly in Visma rather than re-keying them. Month-end close is faster because the supplier invoice history and GL are already reconciled.

What you can do

• •Poll Tradeshift supplier invoices and purchase orders daily or on-demand and post them into Visma as supplier invoices with correct GL allocations.
• •Parse UBL 2.0/2.2 XML line items from Tradeshift documents and distribute invoice amounts across the correct Visma GL accounts and cost centers.
• •Map suppliers from Tradeshift to Visma master data and flag missing suppliers so the integration can replay the invoice once the supplier is added.
• •Authenticate Tradeshift with OAuth 1.0a signing and Visma with OAuth 2.0, managing token refresh and required headers for both platforms.
• •Track invoice status changes from Tradeshift and sync them into Visma so accounts payable records stay current and audit trails are complete.

Questions

Which direction does data move between Visma and Tradeshift?

The primary flow is from Tradeshift into Visma. Supplier invoices and purchase orders are polled from Tradeshift and posted into Visma as supplier invoices with GL allocations. Supplier master data can be synced bidirectionally if both platforms are enabled to write. Invoice status updates (acknowledged, paid, rejected) flow from Tradeshift into Visma to keep the accounts payable record current.

How does ml-connector handle Tradeshift's UBL document format and Visma's GL account structure?

Tradeshift documents are delivered in UBL 2.0/2.2 XML with line items that include quantities, amounts, and cost allocation codes. ml-connector parses each line, maps the allocation code to the corresponding Visma GL account and cost center (dimension), and creates a multi-line supplier invoice with one journal entry per cost allocation. If a GL account or cost center does not exist in Visma, the record is queued and flagged in the audit trail for manual review.

Why does ml-connector poll Tradeshift instead of relying on webhooks?

Tradeshift's polling API with the changedAfter timestamp filter is the most reliable method for continuous synchronization. While Tradeshift event streams are available for registered plugins, polling ensures no invoices are missed and simplifies state management across both platforms. ml-connector polls on a schedule you define, typically daily or on-demand when your AP process begins.