Visma and TrueCommerce integration

What moves between them

Purchase orders and invoices from TrueCommerce flow into Visma as supplier purchase orders and invoices, mapped to the matching Visma supplier records. Supplier data such as names, contacts, and payment terms flow from Visma back to TrueCommerce so trading partner records stay in sync. The sync typically runs on a daily or twice-daily schedule tied to your order-to-cash cycle. TrueCommerce handles acknowledgments and functional notifications via X12 997 messages keyed on ISA control numbers; ml-connector maps these back to Visma PurchaseOrder records so you can track progress.

How ml-connector handles it

ml-connector stores TrueCommerce credentials (SFTP username and password, or API key if using Exchange API) encrypted in the database and polls TrueCommerce's SFTP or managed API on a schedule you define. On the Visma side, it obtains an OAuth 2.0 token using client credentials, includes the ipp-company-id header on every request, and refreshes the token when a call returns 401. Incoming purchase orders and invoices are parsed from EDI X12 format or flat file and transformed into Visma SupplierInvoice and PurchaseOrder entities, then created via Visma's REST API with ETag validation. Supplier records are read from Visma and pushed back to TrueCommerce to keep your partner network current. If a transformation or API call fails, the record is queued for replay, and a full audit trail tracks every exchange between the systems.

A real-world example

A mid-sized manufacturing or distribution company runs Visma.net ERP for accounting and procurement and uses TrueCommerce as its EDI gateway to a network of suppliers and logistics partners. Before the integration, inbound purchase orders and invoices from TrueCommerce were downloaded to CSV or viewed in the TrueCommerce portal, then manually entered into Visma as supplier documents - a process that was slow, error-prone, and kept AP staff busy with data entry. With Visma and TrueCommerce connected, each purchase order and invoice flows into Visma automatically, matched to the correct supplier record, and posted to AP. The manual keying step is eliminated, invoices post faster, and your supplier data stays current across both systems.

What you can do

• •Automatically create supplier purchase orders in Visma from inbound EDI purchase orders received via TrueCommerce SFTP or managed API.
• •Post supplier invoices into Visma accounts payable from TrueCommerce EDI or flat-file invoices, matched to the correct supplier and GL accounts.
• •Sync supplier name, contact, and payment term changes from Visma back to TrueCommerce so your partner network data stays current.
• •Authenticate Visma with OAuth 2.0 client credentials and manage TrueCommerce provisioned SFTP or API credentials securely, refreshing tokens as needed.
• •Run scheduled polling on your order-to-cash cadence with a full audit trail and replay capability if a downstream transformation or API call fails.

Questions

Which direction does data move between Visma and TrueCommerce?

The main flow is from TrueCommerce into Visma. Purchase orders and invoices from your trading partners arrive via TrueCommerce EDI and are transformed into Visma supplier documents. Supplier records flow from Visma back to TrueCommerce so your partner network has current data. Payment and invoice status updates can also flow back via TrueCommerce functional acknowledgments.

Does ml-connector work with both Visma's webhook and polling modes?

ml-connector uses polling to read from TrueCommerce because TrueCommerce's primary mechanism is scheduled file pull from SFTP or managed API, not webhooks. On the Visma side, ml-connector polls Visma's APIs directly using lastModifiedDateTime parameters to detect changes, rather than relying on Visma webhooks which carry no automatic retry guarantee.

How does ml-connector handle the different auth models on each side?

TrueCommerce credentials are provisioned by TrueCommerce during onboarding and stored encrypted in ml-connector's database. Visma requires OAuth 2.0 with a client_credentials grant, which ml-connector handles automatically, refreshing the token when calls return 401 and including the ipp-company-id header on every request. Both auth flows are transparent to you - set credentials once during setup and the integration handles renewal.