Visma and Tipalti integration

What moves between them

Supplier and invoice data flow from Visma into Tipalti. When a new supplier is registered in Visma, ml-connector creates a Tipalti payee record (triggering the Tipalti compliance workflow if configured). When an invoice is created in Visma, ml-connector creates a corresponding bill in Tipalti, linked to the matching payee. Invoice updates in Visma (e.g., amount or due date changes) flow through as bill updates in Tipalti. Payment status changes in Tipalti (approved, submitted, completed) are logged for audit but do not flow back into Visma, since Visma owns the original invoice record.

How ml-connector handles it

ml-connector obtains OAuth2 tokens from both Visma Connect and Tipalti, then polls Visma on a schedule tied to your invoice cycle (typically daily or every few hours). For each new or updated supplier in Visma, it constructs a SOAP payee creation call to Tipalti, mapping Visma's supplier entity (name, address, contact) to Tipalti's required payee fields. For each new or updated invoice in Visma, it creates or updates a Tipalti bill, mapping Visma's invoice amount, due date, and GL account to Tipalti's bill schema, and linking it to the correct payee via external reference. Tipalti's IPN webhook notifies ml-connector of payment events, which are logged for audit (e.g., when a payment is approved or submitted). When Tipalti is offline or returns an error, ml-connector backs off and retries on the next poll cycle. Because Visma webhooks do not auto-retry, ml-connector uses polling as the primary sync method and treats incoming IPN events as confirmation, not primary source.

A real-world example

A Nordic software company with offices in Stockholm, Copenhagen, and Oslo uses Visma.net ERP to manage purchasing and invoicing across all sites. They pay 200-300 suppliers monthly via Tipalti for cloud services, contractors, and vendors. Before the integration, the accounts payable team manually copied supplier names and invoice details from Visma into Tipalti, often re-typing amounts and mismatching invoices to payees when a vendor had multiple contracts. With Visma and Tipalti connected, each new supplier in Visma auto-creates a Tipalti payee, and each invoice syncs over with the correct amount, due date, and GL allocation. The AP team now runs payment sweeps in Tipalti with confidence that every bill traces back to the original Visma invoice, and month-end audit against the original purchase records takes minutes instead of hours.

What you can do

• •Sync suppliers from Visma to Tipalti as payees, triggering compliance and onboarding workflows.
• •Create and update bills in Tipalti from Visma invoices, with amounts, due dates, and GL accounts mapped correctly.
• •Convert between Visma REST/JSON and Tipalti SOAP/XML on the fly, handling auth and envelope transforms.
• •Log payment events from Tipalti webhooks for audit and reconciliation back to original Visma records.
• •Poll Visma on a schedule and retry failed syncs, with a full audit trail on every record created.

Questions

What data moves between Visma and Tipalti?

Suppliers and invoices move from Visma into Tipalti as payees and bills. Payment status events flow from Tipalti back to ml-connector for logging, but the original Visma invoice remains the source of truth. Purchase orders and payment runs are created in Tipalti based on Visma's procurement data.

How does ml-connector handle the difference between Visma REST and Tipalti SOAP?

ml-connector translates between the two. It reads Visma's REST/JSON supplier and invoice data, then builds SOAP/XML envelopes for Tipalti's PayeeFunctions and BillFunctions. Authentication is bridged separately on each side: OAuth2 for Visma, HMAC-SHA256 or OAuth2 for Tipalti, depending on which endpoint is used.

What happens if a Tipalti payee fails to create due to a compliance hold?

Tipalti returns an error response (e.g., duplicate payee or missing required field). ml-connector logs the error with the Visma supplier ID and retries on the next poll cycle. The Visma record is not deleted; the sync waits until the compliance issue is resolved or the supplier is corrected.