Visma and ServiceTitan integration

What moves between them

The primary flow runs from ServiceTitan into Visma. Service invoices created in ServiceTitan post into Visma as customer invoices, mapped to the matching Visma customer and GL accounts. When field-service jobs are complete, ServiceTitan generates AP bills from purchase orders, and ml-connector reads those bills and writes them into Visma as supplier invoices. Vendor records and tax zones are synchronized bidirectionally to keep both systems aligned. Customer and vendor dimensions in Visma are mapped to ServiceTitan business units and customer segments.

How ml-connector handles it

ml-connector caches ServiceTitan bearer tokens and refreshes them when the 15-minute lifetime expires, sending the App Key header on every request to prevent 401 errors. On the Visma side, it stores the tenant_id per customer and prepends the ipp-company-id header to all calls for proper company isolation. It reads ServiceTitan invoices and AP bills either via webhooks (with HMAC signature verification) or polls at a schedule you define. Before posting an invoice into Visma, it validates that the referenced customer and GL account exist and are active in the target company, falling back to a default GL account if needed. Because AP Bills in ServiceTitan are read-only and generated when a purchase order is marked received, ml-connector polls for those events rather than writing back. Retries on Visma PUT failures (e.g., locked ETag) are handled with exponential backoff. Every record carries a full audit trail, including the source invoice number, the ServiceTitan timestamp, and the Visma journal entry ID.

A real-world example

A mid-sized plumbing and HVAC contractor runs ServiceTitan for scheduling, dispatch, and field invoicing across multiple service locations. The office accountant uses Visma.net to manage AP, AR, and the general ledger. Before the integration, the accountant received CSV exports of completed jobs and invoices from ServiceTitan each week, then manually entered them into Visma as customer invoices and matched them to vendor bills from the parts suppliers. Month-end closing meant chasing discrepancies between ServiceTitan and Visma revenue and spending. With ServiceTitan and Visma connected, each completed job invoice flows automatically into Visma's AR, and parts bills post to AP on the correct cost center or project code. The accountant now spends zero time on data entry and can close the books immediately after the last job of the month.

What you can do

• •Post service invoices from ServiceTitan into Visma as customer invoices, mapped to customer accounts and revenue GL accounts.
• •Sync AP bills from ServiceTitan purchase orders into Visma as supplier invoices on the correct vendor and GL accounts.
• •Keep vendor records and tax zones aligned between ServiceTitan and Visma so invoices post to valid accounts.
• •Handle ServiceTitan App Key headers, 15-minute token lifetime, and Visma tenant_id and ipp-company-id headers transparently.
• •Verify customer and GL account existence in Visma before posting, with fallback mapping and full audit trails on every record.

Questions

Which direction does data flow between ServiceTitan and Visma?

The primary flow is ServiceTitan into Visma. Service invoices and AP bills flow from ServiceTitan into Visma as customer and supplier invoices. Vendors, tax zones, and customer records are synchronized bidirectionally so both systems reference the same entities. GL accounts in Visma are never written back to ServiceTitan because ServiceTitan does not expose a chart of accounts API.

How does ml-connector handle ServiceTitan App Keys and Visma tenant IDs?

ml-connector sends the ServiceTitan App Key header on every request and refreshes the bearer token when it expires after 15 minutes. On the Visma side, it stores the tenant_id and ipp-company-id per customer and includes them on all API calls. Both are encrypted and rotated if credentials are updated in ml-connector's UI.

What happens if a customer or GL account does not exist in Visma when an invoice arrives from ServiceTitan?

ml-connector validates that the customer and GL account exist before posting. If a required account is missing, it logs the failure with the source invoice number and can replay the record once the account is created in Visma. Alternatively, a default GL account can be configured so invoices land on a holding account for manual review.