Visma and Avalara integration

What moves between them

The main flow is Visma into Avalara and back. When a customer sales transaction posts in Visma, ml-connector reads the transaction details, compiles customer address, line items, and amounts, and sends them to Avalara's CreateTransaction endpoint. Avalara calculates the applicable tax for that customer's jurisdiction and returns the tax amount, tax rate, and tax code inline. ml-connector then writes those calculated values back into Visma by updating the transaction record with the tax code and recording the tax amount in a custom dimension or subaccount. This ensures Visma's GL reflects the correct tax liability and every transaction is audit-ready. The sync runs on a schedule tied to your transaction volume, typically checking for new or modified Visma sales transactions at the close of each business day, or near real-time if you enable low-latency polling.

How ml-connector handles it

ml-connector stores Visma OAuth 2.0 credentials and Avalara HTTP Basic Auth credentials encrypted, refreshing the Visma bearer token before expiry since refresh tokens are not issued. On each sync run, it queries Visma for customer sales transactions modified since the last check, filtering via lastModifiedDateTime. For each transaction, it extracts the customer address, validates it against Avalara's address resolver to catch invalid jurisdictions that would cause tax calculation to fail, then posts the transaction to Avalara's CreateTransaction endpoint. Avalara returns the calculated tax amount and code synchronously. ml-connector then updates the Visma transaction record with an ETag-based optimistic lock, as Visma requires ETag and If-Match headers on PUT operations. If a transaction code has already been posted to Avalara as committed, ml-connector detects the DocumentCodeConflict error and skips it, treating it as idempotent. Rate limits from Avalara return HTTP 429; ml-connector backs off and retries with exponential jitter. A full audit log tracks each transaction sent to Avalara, the calculated tax, and any errors or mismatches found during reconciliation.

A real-world example

A Nordic distribution company runs Visma.net ERP for order-to-cash and financial accounting, selling to customers across Sweden, Denmark, and Germany with different tax rates and compliance rules per country. Before the integration, the finance team reviewed each day's sales transactions, manually looked up tax rates for each customer's location on Avalara's rate tables, entered the tax amounts into Visma by hand, and then spent the first week of month-end close reconciling the posted tax totals to what Avalara said they should be. With Visma connected to Avalara, every transaction is tax-calculated automatically as it posts, the rates are correct for each jurisdiction, and the month-end tax liability is already locked down and audit-ready. The manual lookups and reconciliation step are gone.

What you can do

• •Send customer sales transactions from Visma.net to Avalara for real-time tax calculation across multiple jurisdictions.
• •Receive calculated tax amounts and codes from Avalara and write them back to Visma transaction records.
• •Validate customer addresses against Avalara address resolver to prevent tax calculation failures.
• •Authenticate Visma with OAuth 2.0 and Avalara with HTTP Basic Authentication using Account ID and License Key.
• •Poll Visma for modified transactions on a schedule tied to your transaction volume, with retries, address validation, and a full audit trail.

Questions

What happens if a customer address is invalid in Avalara's system?

ml-connector pre-validates addresses using Avalara's address resolver endpoint before posting a transaction. If an address is invalid or not recognized, ml-connector flags the transaction, does not send it to Avalara, and logs the error so the finance team can correct the customer record in Visma and reprocess it. This prevents tax calculation failures and keeps your GL clean.

Does ml-connector handle Avalara rate limits and retries?

Yes. Avalara enforces rate limits and returns HTTP 429 when thresholds are exceeded. ml-connector detects 429 responses, backs off with exponential jitter, and retries the request automatically. If a retry succeeds, the transaction is processed normally; if all retries fail, the transaction is logged and can be replayed once rates reset.

How does ml-connector ensure idempotency when posting transactions to Avalara?

Avalara uses document codes as idempotency keys: reusing the same document code returns a DocumentCodeConflict error instead of creating a duplicate. ml-connector tracks which Visma transactions have been posted to Avalara and skips already-posted codes, treating the error as idempotent. If a Visma transaction is reprocessed, ml-connector does not create a duplicate in Avalara.