Visma and Databricks integration

What moves between them

Visma journal transactions, invoices, and GL accounts flow into Databricks tables in a raw layer, mapped to Databricks schema hierarchy via Unity Catalog. Supplier and customer masters are synced to support reference joins. The flow is one-directional, from Visma into Databricks; Visma is the source of truth for all financial records. Syncs run on a daily or ad-hoc schedule to keep the warehouse current with Visma changes.

How ml-connector handles it

ml-connector obtains OAuth tokens from both Visma Connect and the Databricks workspace, caching them until expiry and refreshing on demand. It polls Visma journals and invoices using lastModifiedDateTime deltas to fetch only changed records, and maps Visma GL accounts to Databricks table schema. On the Databricks side, it obtains or creates tables in the configured Unity Catalog and schema, then appends or upserts transaction rows using SQL INSERT or MERGE statements. Because Databricks token expiry is 3600 seconds, ml-connector refreshes on every batch to avoid 401 errors mid-transaction. Visma webhook events, when enabled, can supplement polling to reduce latency. Every record includes Visma record_id and lastModifiedDateTime for lineage and deduplication. If a Databricks write fails, the job is queued for retry with the same idempotency key, ensuring the same records never duplicate.

A real-world example

A Nordic software company with operations in Sweden, Norway, and Denmark runs Visma.net for accounting across three legal entities and uses Databricks as their central data platform for consolidated reporting and audit analytics. Before the integration, the finance team exported GL transactions from Visma monthly, loaded them to CSV, and ran custom Python notebooks to deduplicate, validate, and consolidate across entities. With Visma and Databricks connected, journal entries flow automatically into Unity Catalog tables every day, and the finance team queries a single consolidated GL from Databricks, month-close reports run on up-to-date data, and the manual export and validation work is eliminated.

What you can do

• •Pull Visma GL transactions, invoices, suppliers, and customers into Databricks tables on a daily or ad-hoc schedule.
• •Handle OAuth 2.0 flows for both Visma Connect and Databricks service principals, with automatic token refresh every 3600 seconds.
• •Map Visma GL accounts and dimensions to Databricks schema and Unity Catalog structure for consistent downstream queries.
• •Use Visma delta polling with lastModifiedDateTime to fetch only changed records and reduce API calls.
• •Deduplicate records via record_id and handle retries with idempotency keys to prevent duplicate rows in Databricks tables.

Questions

Which direction does data move between Visma and Databricks?

Visma is the source of truth. Financial records, GL accounts, invoices, suppliers, and customers flow from Visma into Databricks tables. Databricks is read-only; ml-connector does not write back to Visma. The one-directional flow keeps the warehouse in sync with Visma while preserving Visma as the authoritative source.

How does the integration handle Visma webhooks and Databricks token refresh?

Visma webhooks are one-time delivery with no automatic retry, so ml-connector uses polling with lastModifiedDateTime deltas to fetch changes reliably. Databricks tokens expire every 3600 seconds, so ml-connector obtains a fresh token before each batch of writes and refreshes on demand if a call returns 401. Together, these approaches ensure reliable data delivery without loss.

Does the integration require manual mapping of Visma GL accounts to Databricks tables?

No. ml-connector accepts a Unity Catalog schema and a mapping of Visma GL account codes to Databricks column names or table partitions, configured once at setup. Thereafter, every transaction is routed to the correct table based on its GL account, and the same mapping applies to every sync cycle, keeping the warehouse structure consistent.